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."
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.
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.
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.
Pretty clear and standardised to me.
-- Lattyware (www.lattyware.co.uk)
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".