Slashdot Mirror
Python 3.0 Released
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."
← Back to Stories (view on slashdot.org)
Comment removed based on user account deletion
Python 3 being out is great, they've fixed a few things that allow bad programming, but does anyone know how long it will take for the libs to start getting ported? Especially numpy and scipy
previous releases were incompatibilie with earlier ones unintentinally.
The release notes might interest people:
http://docs.python.org/dev/3.0/whatsnew/3.0.html
Also note that in the end of the release notes are info on the migration path from Python 2 to 3. I'll leave the rest to people who bother to RTFA... ;)
.: Max Romantschuk
The cool thing about Python is it's "time machine". In Python 2.x you can "from __future__ import " to use features scheduled for future releases. With the release of Python 2.6 there's also a "2to3" tool that will point out revisions needed for 2.x code to be 3.0-compatible, and generate patches for you.
The Python developers have been aware of the difficult road of migration long before the release of Python 3, and they did a lot of careful planning and hard work for it. One of them being the __future__ module that has been there for quite long time just for this reason.
As a Python user, my hat off for them. I wish them success heartily.
BTW: In case you don't know, there's an Easter egg in the time machine: "from __future__ import braces" ;)
Colorless green Cthulhu waits dreaming furiously.
Sounds great! Now to wait a few weeks while smart people find and fix all the security holes, so I can go and safely get version 3.1.
Where's the mac version..?
MABASPLOOM!
Yes, Python 3.0 is a break.
But in the past and forseeable future, Python has been exceedingly helpful, much more than most languages, during upgrades.
Usually one has several months to try out new features-- they're in the current version but turned off until you ask for them with "future_builtins".
Plus there's often a backwards feature in the next version to revert back to old behavior.
Not to mention a -3 option to point out the lines in your old program that will need changing for version 3.
But sometimes the changes are so big they can't be encompassed by a compiler switch. Such it is with 3.0.
But I just came in here for an argument!
I'm fairly certain they got all these non-backward compatibility issues out of the way with this release so they don't have to do this kind of thing again for a long while. My guess is, they wont ever put out a non-backwards compatible release, since those changes were mostly to fix poor coding practices like being able to run certain functions without braces (e.g print "hi").
MABASPLOOM!
OK, never mind, I just saw it, there seems to be such a beast: http://docs.python.org/dev/3.0/library/2to3.html#to3-reference
Like http://docs.python.org/library/2to3.html, perhaps?
SyntaxError: maybe in 3.5
Reworked Unicode support is a big deal. It was there before, of course (unlike Ruby - meh), but all those Unicode strings vs 8-bit strings, and the associated comparison issues, complicated things overmuch. Not to mention the ugly u"" syntax for Unicode string literals which was too eerily like C++ in that respect. Good to see it move to doing things the Right Way by clearly separating strings and byte arrays, and standardizing on Unicode for the former.
Now, if only we could convince Matz that his idea for Unicode support in Ruby 2.0 - where every string is a sequence of bytes with an associated encoding, so every string in the program can have its own encoding (and two arbitrary objects of type "string" may not even be comparable as a result) - is a recipe for disaster, and take hint from Python 3...
So what are you going to do, take all your existing Python applications and rewrite them in a different language, in order to avoid the "significant amount of work to maintain existing functionality with new language version"?
AccountKiller
As someone mentioned above, try
from __future__ import braces
and see what happens. ;)
As for Ruby, I don't really follow its development or use it, but I was reading just the other day that they're really focused on finishing 1.9, which does byte-compiling and some optimization. The current version (like JS before spidermonkey, V8, and squirrelfish) walks and executes the AST (as I understand it), which is slooow.
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.
-><- no
For the lazy (or those who don't have python installed at work):
>>> from __future__ import braces
File "<stdin>", line 1
SyntaxError: not a chance
"I think an etch-a-sketch with an ethernet port would beat IE7 in web standards compliance."
It's also cleanup of some stupid syntax that was there for ages. For example, exception handling. Old style:
New style:
It's fairly obvious that the latter is much clearer.
First thing mentioned on the 'what's new' page (http://docs.python.org/dev/3.0/whatsnew/3.0.html)is that you'll have to change your code from
print x, y, z,
to
print(x, y, z, end="")
I can see the value of making things more consistent, but it seems to me whenever they update things in Python, it's usually to make programming in it a little bit harder.
Why not make print a function, but then change the language to not require parentheses for any function call? You'd still have to use them when calling a function with zero arguments, and in sub-expressions, but to not require parens for top-level function calls would, if nothing else, make playing around in interactive mode or with short scripts a lot more pleasant.
Granted, I come from a Ruby background, so I may not know what I'm talking about. My experience with Python is trying to write some scripts on my OLPC, where the craptacular rubber keyboard made typing parentheses all the more agonizing. I finally caved and installed Ruby so I could get some work done. Maybe people who prefer Python really like typing parens. And underscores.
Duct tape, XML, democracy: Not doing the job? Use more.
That'll be when Perl 6.0 ships.
AFAIK Perl 6.0 is already there, in the form of Pugs (which is said to be compatible with all the specs), and it's just the implementation of Perl 6 in perl6 itself what people are waiting for. You can go and write actual Perl 6 code, and run it on Pugs, and it'll work.
I heard they're going to use Python 3.0 for the impending from-scratch rewrite of DNF.
No you didn't.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Cut-n-paste is not a good way to learn.
Between Python's extremely verbose syntax (not very script-friendly-like)
It's not extremely verbose; take a look at Java if you want that. If you compare with e.g. perl, yes it's longer, but the difference is because it's using words rather than random characters, which in my book is worth it for the ease of remembering wtf to write. Compare it with Ruby or, *struggles to think of another scripting language* TCL, say, and the verbosity is pretty similar.
and relatively poor performance...
Really? It's not going to win races against C, but performance is very much on a par with say Perl (which yes, has a lot of improvements coming in v6, but that's not here yet), and ahead of other similar languages. Couple with the fact that it's easier to bind from python than any of the alternatives, and you end up with code that in practice is as fast as you could write anywhere (because you use e.g. NumPy, which just binds to the fastest libraries available for doing what it does).
Of course python does sacrifice some things - but the ease of code writing and most of all maintainability are well worth it in most cases, in my experience.
I am trolling
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>
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
What whitespace problem?
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.
Property for sale in Nice, France
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.
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 ...
Are you typing while drunk?
"I think it would be a good idea!"
Gandhi, about Internet Security
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.
retrorocket.o not found, launch anyway?
Interestingly, it IS backwards compatible in areas that you wouldn't think it should be. For instance, the following program takes the version number, adds one to it, and divides by two. You'd think it'd give a different answer between version 3 and version 2. Glad they kept this program working for me, as it's the secret production code that runs my multi-million dollar business.
import sys
version=int(sys.version[0])
print (version+1)/2
Prints 1 in either version. (on the bright side, 1/2 is now 0.5!)
oops I really screwed that joke up... crap. somebody fix it.. you know what I was trying to do!
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.
too bad it doesnt install from source out of the box, even with libgdbm-dev installed
make
running build
running build_ext
Failed to find the necessary bits to build these modules:
_dbm
To find the necessary bits, look in setup.py in detect_modules() for the module's name.
see bug here. Why they would announce a release that wouldn't build for a major distribution such as ubuntu baffles me.
Signs of the apocalypse:
* A black man was elected President of the US - November 4, 2008
* Chinese Democracy was released - November 23, 2008
* Python 3000 is released - December 4, 2008
* ?
* ?
* Large Hadron Collider starts operations - ?
* Duke Nukem Forever is released - ?
No sig for the moment.
I think you should use a few more posts to explain the joke. The more you go on the funnier it gets. :)
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 ...
Are you typing while drunk?
No, he generated that comment with Python 2.6 code but ran it with the new release.
An argument isn't just contradiction!
Yes it is.
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.
factor 966971: 966971
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.
True Part:
In Python version 2, 1/2 = 1 (integer math)
In Python version 3, 1/2 =0.5 (floating point math)
Funny part:
You can do some math on the version number and it comes out the same, even though the version number has changed. Because the divide operation changed too.
wait, it's not so funny after all. What was I smoking?
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
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.
True Part:
In Python version 2, 1/2 = 1 (integer math)
1/2 in Python 2.x is actually 0.
It's scary to code something while drunk then come back the next day and think "god, whoever wrote this is clever".
I don't even need to be drunk! That happens to me regularly ... ah the ageing process.
Better to be despised for too anxious apprehensions, than ruined by too confident a security. --Edmund Burke
>>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.
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)?