Python 3.0 Released 357
licorna writes "The 3.0 version of Python (also known as Python3k and Python3000) just got released few hours ago. It's the first ever intentionally backwards-incompatible Python release."
This discussion has been archived.
No new comments can be posted.
Python 3.0 Released
Related Links Top of the: day, week, month.
An Ada exception is when a routine gets in trouble and says 'Beam me up, Scotty'.
Re:That marks my end of use for Python (Score:3, Insightful)
Besides teh above remark of well thoguth migration paths - it is importante to remakr that support for python 2.x has not ended in any way.
As far as Iam aware, the recomendation is to keep working with python 2.6 - and use the py2to3 script to regularly to make 3.0 releases if you you can (i.e. if your dependencies have 3.0 versions already).
No need to worry about anything, this will be a smooth, years long, transition. Chances are we will even see a python 2.7 before 2.x is officially deprecated.
Re:Libraries (Score:5, Insightful)
Backward compatibility is (i) over-rated and (ii) misunderstood.
It is over-rated in the sense that the number of current users which are inconvenienced is a very small percentage of the total number of users of the language (unless the language is in the tail end of its life, like Fortran and Cobol).
It is misunderstood in that with the use of a simple header or import declaration it is possible to have two different versions co-exist while the transition happens. This is done in HTTP where the first thing that clients exchange is the version of the protocol they'll use. It is also done in LaTeX, where the first declaration informs the compiler which major version is being used (pre-2e or 2e).
Kudos for Python for not being afraid to rock the backwards compatibility boat.
Re:I'll still avoid it (Score:4, Insightful)
As they didn't fixed the stupid forced-indentation thing.
Same reason I don't use C... that stupid forced-curly-brace thing. Why can't the language just know what I want to do?
</sarcasm>
Re:I'll still avoid it (Score:3, Insightful)
It's good thing when you get used to it as it makes source code much clearer. If you find that the forced indentation is bulking up your code too much then you are probably missing a trick... in Python there is always a short-cut and you just have to think more Python-like. For example in C/PHP I would type:
x=1; y=2; z=3;
When you first look at Python you are tempted to write:
x=1
y=2
z=3
Quickly you find you can:
x,y,z = 1,2,3
Phillip.
Re:Hey! (Score:3, Insightful)
Care to cite a reference for the Rossum's alleged comment? I think "the whitespace problem" is actually one of Python's big advantages, since it greatly enhances program readability.
Re:I'll still avoid it (Score:3, Insightful)
For a little bit I avoided Python because of the whitespace sensitivity.
At some point I gave it a try, at which point I was already using emacs. It took 5 minutes to get used to the whitespace sensitivity since emacs took care of indentation for me.
Re:I'll still avoid it (Score:5, Insightful)
Well, the big issue I've run into with Python is when you are editing across multiple text editors, where some might use tabs, and some might use spaces. This seems to trip up Python where it wouldn't mess with a brace delimited language or something with an "end" syntax like Ruby.
Re:Libraries (Score:3, Insightful)
Python 3 being out is great, they've fixed a few things that allow bad programming
Really? So if I write code in Python 3, it's guaranteed to be "good" programming?
Honestly, I didn't look at the article... have they actually made things MORE rigid?
I use python... I like python... but I can't help but think it was designed by someone who was pissed off that people didn't format their code the way he formatted his code. Since his way was obviously the "right" way, why not write a language that forces you to do it that way? Problem solved! I love the addition of artificial barriers like being able to make your code fail if you mix spaces and tabs in your indents. Nothing anal retentive about that!
Sorry, just ranting... I really do use and like it, just some of it seems so anal retentive to me, and the thought that you can "fix things" that allowed bad programming seems like it's even more so.
Re:print function (Score:3, Insightful)
Why not make print a function, but then change the language to not require parentheses for any function call?
A good argument is that it would make the grammar ambiguous.
What's the parse tree of "f x, g y"? I think it can be both (tuple (f x) (g y)) and (f x (g y)).
One could of course detect and disallow ambiguous strings, at the expense of the parser having to do a little more work. It may be a little, or it may be a lot. ...
Re:Libraries (Score:5, Insightful)
Fortran will continue to thrive for many years.
I agree. The point is that the number of current users is a non-negligible percentage of the universe of future users. It is in that sense that it is "near the tail end".
For languages which are very early in their life cycle, such as Python, the number of users inconvenienced today are negligible compared to the total number of users that it will have and benefit from the changes.
Re:Libraries (Score:2, Insightful)
"Sorry, just ranting... I really do use and like it, just some of it seems so anal retentive to me [forced indentation]..."
I ranted about that too when I first started using Python. But when I noticed how nice it was to read other peoples' code, I concluded that it was a good thing.
Re:I'll still avoid it (Score:3, Insightful)
the biggest problem is not copying from external sources, but moving your own code around.
of course the final code should get the right indentation anyway, but it's annoying to force the indentation when you just want to do a quick test.
and I don't write messy code. on the contrary, I'm a perfectionist zealot when it comes to the details of code aesthetics. it's just that forcing it is a bad design decision.
Re:I'll still avoid it (Score:4, Insightful)
Cut-n-paste is not a good way to learn.
Ah, I see, you've never refactored code before. Well, good for you, apparently everything you write is either immediately perfect, or you never have to maintain it!
Here in the real world, however, we *do* have to cut and paste blocks of code occasionally, and Python makes that annoyingly difficult.
Re:Libraries (Score:5, Insightful)
I can't help but think it was designed by someone who was pissed off that people didn't format their code the way he formatted his code. Since his way was obviously the "right" way, why not write a language that forces you to do it that way? Problem solved!
This is actually the main reason I haven't worked with Python beyond tweaking a few existing scripts. The funny thing is that (unless I'm misremembering the syntax) I already code using that style in other languages. But the idea of forcing that style on everyone annoys me enough to put me off of the language as a whole.
I was really hoping that 3.0 would remove that petty stupidity. Doing so would even retain backwards compatibility with prior versions!
I just don't get it when people say that, its sorta like saying you don't use language X because you have to store numbers as floats or integers instead of char variables.
I honestly like the fact that Python forces a coding format, I hate opening someone else's source and spending the first minutes trying to understand how they layout things if at all. And yes if people were smart it would be easy to pickup anyones code, sadly that world doesn't exist.
No its not petty stupidity, not using Python because of your reasons is sadly what I would call petty stupidity.
Re:That marks my end of use for Python (Score:2, Insightful)
those changes were mostly to fix poor coding practices like being able to run certain functions without braces (e.g print "hi").
Minor quibble: print wasn't a function, it was a statement. That is, it was on the same level as if/then, while, import, etc.
The thought is, though, that print is nowhere near as "central" to the language as if/while/import, and its functionality could just as well be handled with a function. - Which is what they did with 3.0
Re:Libraries (Score:5, Insightful)
I wonder if Fortran may eventually be replaced by Python.
Already has been, in my world. I know plenty of people around the chem department who still use Fortran because 'it is the language of scientific computing, dammit!'
Here is the thing. Most of the time, they were so panicked about how long the program would take to run, they lost sight of how long it took them to write it.
I replaced many Fortran programs with Python in my time, because I could write the data IO so much faster, and then just use the C-level numerical libraries to do the analysis. The program would end up running just as fast, and the code could be written in an hour instead of a week.
Some people will die before they change languages. The rest of us just want our results. Hopefully, the switch to py3k goes easy and the community continues to grow.
Re:print function (Score:2, Insightful)
Re:I'll still avoid it (Score:3, Insightful)
I have this code:
def myfunc()
if some_thing:
do_something
do_something_else
last_thing
def myfunc2()
while another_thing:
myfunc()
one_other_thing
And I decide i want to collapse those loops, so I copy and paste the code:
def myfunc2()
while another_thing:
if some_thing:
do_something
do_something_else
last_thing
one_other_thing
There is *no way the editor can handle this correctly*. It will always get it wrong somehow. After all, how can it know that the if block *and* last_thing should be indented so it's included in the while statement? Worse, when it gets it wrong, it'll change the semantics of the code. And *you won't know*, because the code will continue to parse correctly.
Of course, this is just one, somewhat contrived example. But I have, on numerous occasions, endured cases where refactoring has been made *much* harder thanks to Python's lack of a block termination marker. If you haven't encountered such cases, I would contend you've never had to maintain a non-trivial Python codebase.
Re:I'll still avoid it (Score:1, Insightful)
I think if you ran a poll on what's keeping people from using Python, this one would rank pretty high. I know it's my number one reason.
Shame, really. Then again, there's Perl, PHP, and Ruby, so no point in whining, I guess.
Why whitespace really is a problem (Score:3, Insightful)
>>Any coder worth his salt is already indenting his code
As long as you are using your own code, and stick to your own conventions, then it's not a problem.
But what about when you are working with code from somebody else? You can not just look at it and tell if the original developer used spaces, or tabs. You have to do a hex dump, or something - what a pain.
And what if you want to cut and paste from a website? Or email code? Or post code to a news group, or whatever? Whitespace can be an issue in any of those cases.
I believe that even Guido has admitted the forced whitespace was a mistake.
Re:ubuntu make fail (Score:3, Insightful)
It seems some headers are not installed (BerkeleyDB? Dunno what's the Ubuntu package name for that. It's "db4-devel" here on Fedora). Just check them out and rebuild?
Anyway, I never expect some 3rd party source tarball to be able to "build right out of the box" for me. If you do something outside a distro's package management system, you'll have to manage the dependencies all by yourself.
Re:I'll still avoid it (Score:3, Insightful)
If you're the one doing the refactoring, then you'll know how far the indentation is wrong, and you can apply the correction.
I *shouldn't have to*. Besides which, the fact that I do introduces a major source of potential error: because indentation is semantically significant in Python, if I screw up during the refactoring process (particularly large scale refactorings), I can actually introduce bugs simply by not getting the indentation right. That's just unacceptable.
So no, I wouldn't think anyone should be even slightly inconvenienced by this when refactoring their own project's code.
Except, of course, I already have, so you're demonstrably wrong.
The markers will all be there though so the editor should be able to get it right, and if not the programmer should.
And those markers would be what? Oh, right... there aren't any, which was my original point. 'course, if the Python devs simply added an 'end' keyword, this entire conversation would be moot.
but in practice it doesn't seem like a big enough issue to avoid using the language.
Given the plethora of competing offerings, I humbly disagree. Why deal with Python's silliness when I could just use, say, Ruby instead? Or Perl (assuming you're not an undisciplined hack)?