Python 3000 is ready(jeremyhylton.blogspot.com)
jeremyhylton.blogspot.com
Python 3000 is ready
http://jeremyhylton.blogspot.com/2008/12/python-3000.html
19 comments
"Also note that as of Python 2.6, the functionality of turtle has been greatly enhanced."
As usual, the changes are early-adoptable to a degree in the preceding Python version (2.6). Just use __future__ imports and try the -3 switch to see deprecation warnings.
I am mostly curious how this will pan out on the Mac. I've released a program that relies on the system Python, which has worked okay so far because the 2.x installations of each Mac OS X version are basically compatible. I hope Snow Leopard ships with Python 2.6 as well (even if it includes 3.0), so that I have more breathing room and code doesn't automatically break. :)
I am mostly curious how this will pan out on the Mac. I've released a program that relies on the system Python, which has worked okay so far because the 2.x installations of each Mac OS X version are basically compatible. I hope Snow Leopard ships with Python 2.6 as well (even if it includes 3.0), so that I have more breathing room and code doesn't automatically break. :)
The chance of Snow Leopard using Python 3.0 as its default python is statistically indistinguishable from 0.
This rant comes from a narrow view point, but I wonder how much Python is going to slip on maintaining things... I've already been using the older Python 2.5 just for PIL (Python Imaging Library) to do pixel by pixel operations on images... I would use PyMedia but it only supports up to 2.3! There might be a better or newer options but I've yet to find them(nor really have the time\skill to update them), so Python 3000 is probably a no-go for me.
I once argued that upgrading ASAP was the Pythonic thing to do. I forget the numerous compelling reasons I had come up with, but that was long before I had to face "shall I move this stable code to the new version, for no major benefit and limitless potential problems?"
I haven't moved it and it's still working (of course!).
I haven't moved it and it's still working (of course!).
I can't believe it's not vaporware.
I can't believe they've ruined years of boasting about how hello world is as simple as "print 'hello world'" by making print a function. :(
I can't believe they've ruined years of boasting about how hello world is as simple as "print 'hello world'" by making print a function. :(
Is print("Hello World") really any different than print "Hello World"? The first seems more clear.
I think print("hello world") is better because it is more consistent (mentally)
Doesn't Python make a distinction between some_method and some_method(), where the first is a direct reference to a Method object (more or less) and the second actually invokes that method?
Yes, all functions are objects. The thing is, "print" used to be a part of the language, not a function, so you couldn't treat it like a function.
Previously: 5 keypresses, Now: 9 keypresses
Previously: 2 characters that aren't directly relevant to what you want to do (print text, the quotes), Now: 4 (quotes and parens).
Previously: No shifted characters, Now: 2 shifted characters
Previously: Inconsistent behaviour, right in the core of the language where you are most likely to benefit from minor savings and least likely to forget about it. Now: Consistent behaviour at the expense of extra typing, visual clutter and, for experienced users, the hassle of changing.
Previously: Python loved for its interactive interpreter, only really possible because Python is concise enough to use in a throw-away fashion.
Yes it's different, the question is, is it an improvement, and is it significant enough to be worth it?
The question is, given all the changes to unicode and classes and iterators and final removing of the int/long split which are all going to play out over big programs and many days/months, why not pick on the color of the bike shed 'issue', extrapolate it over the whole of Py3k and make out of proportion complaints?
Er, wait...
Previously: 2 characters that aren't directly relevant to what you want to do (print text, the quotes), Now: 4 (quotes and parens).
Previously: No shifted characters, Now: 2 shifted characters
Previously: Inconsistent behaviour, right in the core of the language where you are most likely to benefit from minor savings and least likely to forget about it. Now: Consistent behaviour at the expense of extra typing, visual clutter and, for experienced users, the hassle of changing.
Previously: Python loved for its interactive interpreter, only really possible because Python is concise enough to use in a throw-away fashion.
Yes it's different, the question is, is it an improvement, and is it significant enough to be worth it?
The question is, given all the changes to unicode and classes and iterators and final removing of the int/long split which are all going to play out over big programs and many days/months, why not pick on the color of the bike shed 'issue', extrapolate it over the whole of Py3k and make out of proportion complaints?
Er, wait...
[deleted]
I had the same thought. I'm torn on that.
If it was only that.
How about "Unicode, only Unicode, nothing but Unicode"? Doesn't it smell Microsoftish/Sunish? 16-bit data is a pain in the arse, and as long as communication hardware is essentially 8-bit, Unicode will never replace old good 8-bit and UTF. It will only make your I/O programming harder and the programs themselves slower, with no real benefit. UTF-8 gives you a perfect solution for all your localization needs without any special support on the compiler side.
I have mixed feelings about Python "3000". Many changes are meant to bring more consistency (if saying you shouldn't do this because it's bad is called "consistency"), however, as a result Python 3 will successfully make it into the corporate environments, but will never be truly popular among geeks. Stick with 2.6, it's nice.
How about "Unicode, only Unicode, nothing but Unicode"? Doesn't it smell Microsoftish/Sunish? 16-bit data is a pain in the arse, and as long as communication hardware is essentially 8-bit, Unicode will never replace old good 8-bit and UTF. It will only make your I/O programming harder and the programs themselves slower, with no real benefit. UTF-8 gives you a perfect solution for all your localization needs without any special support on the compiler side.
I have mixed feelings about Python "3000". Many changes are meant to bring more consistency (if saying you shouldn't do this because it's bad is called "consistency"), however, as a result Python 3 will successfully make it into the corporate environments, but will never be truly popular among geeks. Stick with 2.6, it's nice.
They introduced a new "bytes" type which is basically just the old "str" type. So you can still do things the old way; if you say b"Hello World!" then it'll give you the bytes type, whereas if you say "Hello World!" then it'll give you the unicode str type.
This is a great first step. The real chore is migrating everything to py3k.
http://docs.python.org/dev/3.0/whatsnew/3.0.html