Slashdot Mirror
Python 3.3.0 Released
An anonymous reader writes "After just over a month of release candidates, the final version of Python 3.3 launched today. This version includes new syntax, including the yield from expression for generator delegation; new library modules, including fault handler (for debugging crashes), ipaddress, and lzma (for data compression using the XZ/LZMA algorithm); a reworked OS and I/O exception hierarchy; the venv module for programmatic access to Python virtual environments; and a host of API changes. The full list of features and the change log are both available."
I think Ubuntu is going Python 3. Most of the scientific stuff has been ported (though the Matplotlib port may be immature).
Bottle, Pyramid, and Tornado are all ported. Just not Django.
It's probably now at the point where new projects are better off starting with Python 3, to ease the pain of upgrading later, unless there's a library they really need. Starting with a mature (but depreciated) platform is not a great idea.
Bottle, Pyramid, and Tornado are all ported. Just not Django.
Ah, I remember when you stood a decent chance of guessing what something did from its name. And all this was cherry orchards, far as the eye could see.
systemd is Roko's Basilisk.
Arch Linux (obviously) is using Python 3 by default for a long time. On the scientific side, numpy/scipy and all that stuff are ported, but a lot of other scientific modules still aren't, which sucks.
If you don't understand any of my sayings, come to me in private and I shall take you in my German mouth.
In mid-August, Django had a blog post 'Experimental Python 3 Support' (https://www.djangoproject.com/weblog/2012/aug/19/experimental-python-3-support/), which talked about the progress they've made so far towards porting the system to Python 3 and how it's coming along well. It's to be considered pre-alpha at the moment, but there's been a lot of progress over this summer.
"It's probably now at the point where new projects are better off starting with Python 3, to ease the pain of upgrading later, unless there's a library they really need. Starting with a mature (but depreciated) platform is not a great idea."
Unless you want to use Python on Google App Engine, where Python 2.7 is what you get. And given that Guido himself works for Google on this project, that's not exactly encouraging.
Or unless you want a Python app to work out of the box on, well, just about anything, but OSX is the example that bit me.
I remember discussing Python 3 on /. when it came out. The decision not to even try to ensure backwards compatibility struck me as disastrous. The response was "No, because Python will never have a cruft problem because we are not Perl coders", or something like that. Many years on, I still think it was disastrous. Python now has a bigger legacy code problem than Perl - seen much Perl 4 recently? - precisely because the upgrade path is such a pain.
Killing Python 2 is going to be like killing IE6 and Windows XP - a noble goal that turns out to take decades. And it's a totally self-inflicted wound by the Python community.
Virtually serving coffee
Killing Python 2 is going to be like killing IE6 and Windows XP - a noble goal that turns out to take decades. And it's a totally self-inflicted wound by the Python community.
Except nobody intends to kill Python 2 anytime soon. When Python 3 was shaped, it was everyones plan to have Python 2 + 3 alongside for a long time.
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
For some reason I can't get "yum install python" to work.
Yeah, if you look at all the old programs, you can always tell what they do. Excel, Access, Gimp, Firefox, Quarkxpress. Sure there's some good names out there like Photoshop, Word, Internet Explorer, WordPerfect and CorelDraw!, but I don't think it was ever the case where the function of most programs could be identified by their name. All the obvious names get taken early on, and you're left with having to give your program a meaningless name so that you don't sound like a copycat, and so you can distinguish your program from all the others out there.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
While I like some of the changes in python3, breaking compatibility with python2 was a huge fail.
From python3 release notes (dated December 3rd, 2008):
'''Python 3.0 (a.k.a. "Python 3000" or "Py3k") is a new version of the language that is incompatible with the 2.x line of releases. The language is mostly the same, but many details, especially how built-in objects like dictionaries and strings work, have changed considerably, and a lot of deprecated features have finally been removed. Also, the standard library has been reorganized in a few prominent places.'''
This was four (4) years ago. Major linux distributions are still on python2. Many python2 packages are still hard to come by for python3. Popular libraries (for example opencv) still link to python2. Even google searches for python docs go to python2.
Python 2.7.3 is the new IE6.
That might be the case, except:
#!/bin/env python
might give you python2 or python3. And there's no standardized way to ask for python2 or python3.
Gimp is a program for cripples?
Ok, that one is self explanatory.
Do you even lift?
These aren't the 'roids you're looking for.
The trouble with Python 3 is that nobody took responsibility for converting the third-party libraries. Many major libraries became abandonware in that transition. Rather than converting the old ones, in some cases, new incompatible libraries were developed. So not only do you have to convert your code from Python 2 to 3 (for which there is a tool to help), you have to change your code to use new libraries. Python doesn't have enough market share that major projects like MySQL and OpenSSL maintain the Python bindings for their project. At one point, the Python binding for OpenSSL was maintained by a World of Warcraft guild.
Perl has CPAN, which actually hosts library source and has some Q/A functions. Python just has PyPi (formerly "Cheese Shop"), which is just a directory of links.
This is Python's real problem. Python's Little Tin God For Life doesn't want the headaches of managing library maintenance. But he's not willing to let go and turn control over to an organization that can manage the grunt work of getting all the parts to work together. That's also why there is no Python ISO standard, and why none of the implementations other than CPython support 3.x.
Sure there is: #!/bin/python3
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
That's what shebangs are for - #!/usr/bin/env python2 means 2.x, python3 means 3.x - don't blame Python because Windows doesn't follow convention. That said, there is a PEP that was accepted for a windows launcher that would do the right thing, but I don't know what the state of that is.
-- Lattyware (www.lattyware.co.uk)
Many of the people here won't get your point, to wit: yum is written in Python. The Mandriva GUI tools that make Mandriva one of the best Linux distributions on the planet are all Python based. In fact, any LAMP stack implementer worth his salt eschews PHP and makes the P stand for Python. You all might also have heard of a company that called Google that would disagree with the AC's ridiculous claim.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Pretty clear and standardised to me.
-- Lattyware (www.lattyware.co.uk)
Googler here. Python is only used in legacy applications -- all new code is written in Go.
The launcher is added with 3.3 and suppose you can install it separately too.
http://docs.python.org/dev/using/windows.html#launcher
Tried and had no problems with python2.7 and python3.3 installed
One reason why Python 3 hasn't taken off is that it didn't adopt .py3 as a file name suffix for Python 3 programs.
A lot of the Python programs I've written don't have any extension on the file name. They're intended to be commands in the system. The language they're written in is an unimportant implementation detail (and might change one day). There's usually no need to make the implementation language user-visible.
In case anyone is wondering, many programs should perform better under Python 3.3 than under 3.2, due to the new way of storing Unicode strings:
The memory usage of Python 3.3 is two to three times smaller than Python 3.2, and a little bit better than Python 2.7, on a Django benchmark.
Benchmarks that focus on certain types of string-operations have seen slowdowns, but real-world applications (such as Django web applications) should benefit from this change. (And real-world applications that perform intensive and performance critical string manipulations should use PyPy.)
There's usually no need to make the implementation language user-visible.
I agree in some cases, such as on a Linux or *BSD server where shebangs or rewriting or type-maps or MultiViews can safely keep the implementation language out of the URL space. But on the Windows desktop, Microsoft tried this with "Hide extensions for known file types", and it led to all sorts of trojans where the user didn't realize that what the user thought was a document was actually an executable.
Well, for one thing C is so basic, that there are fewer places that it needs to adapt. Even so, it *REALLY* needs to improve the handling of unicode strings and utf-8 files. This can't be patched by add-on libraries. And for my purposes, garbage collection would be a real benefit. (I mean standard garbage collection. And a decent garbage collection would mean that you couldn't freely inter-convert integers and pointers, or do pointer arithmetic, though properly constrained pointer arithmetic is feasible. [See Vala.])
If your purposes are different, it's reasonable that you may not need these features. But don't presume that everyone has your same use case.
I think we've pushed this "anyone can grow up to be president" thing too far.
It's a part of PEP 380, which is mostly about "yield from", but this little gem actually matters elsewhere. You can now return values from iterators. I.e.:
Since return from an iterator just raises StopIteration exception, they've added a field to propagate the value. Previously you could only use the no-argument return.
Why this matters is because it gives you the final bit needed to provide full syntactic sugar to write asynchronous functions (task-based, chained callback model - think Node.js, or Twisted in Python land) as if they were synchronous, except that you use "yield" at the points where you want to cooperatively yield control. Of course yield is the bigger part of it anyway, and it was there before, but you had to use some magic function call to implement final return. Now it really looks exactly like a synchronous function, except for "yield".