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.
And...But...I just downloaded 3.2 -_-
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
I'm waiting for that
The size of your need for attention is disturbing.
PS. I'm not a Python fan, I actually dislike it.
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.
Mercedes-Benz SLK, Dodge Viper, Apple iPod, McDonald's, Intel Pentium, Linux, BSD, American Telephone & Telegraph System 5, Netscape Navigator, Sun Solaris, Sun Java, C, ...
For some reason I can't get "yum install python" to work.
That's totally unfair. At least with Pascal you can see all the code.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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.
You have no idea how ignorant you are. Check out the TIOBE index, Python is currently #8 and has never been lower than #13. Pascal is currently #16, and hasn't ever been higher than #14. Python's actually more popular than Javascript, and quite useful for real world programming. You can easily find software made in Python for a variety of uses. There's also a couple good web frameworks for it - Django & Cherrypy. Cherrypy even supports Python3.
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.
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. This makes side-by-side installation of Python 2 and Python 3 much more difficult. Does Python 3.3 yet have a feature where I can have both Python 2 and Python 3 installed on a PC running Windows, and double-clicking a .py file in Windows Explorer runs the correct interpreter version? Until that's fixed, with a .py handler that starts Python 2 or Python 3 depending on future statements or the shebang line, Python 3 won't take off.
Well, semms like we need to standardize that. Virtualenv makes it less of a problem, but does not solve it. Also, you can make code that run on both versions. It is harder, but you can.
Python3 is way better than Python2, and everybody seems to agree on that. Every big project out there either supports or is adding support for it, so killing Python2 may be much easier than IE6.
Rethinking email
if any of y'all want to have some fun then take a stab at converting MakeHuman to Python 3.* (please note if you can get it to run contact the Project Managers)
Of course if you want to play with an Open Source version of Poser you can also have fun.
Any person using FTFY or editing my postings agrees to a US$50.00 charge
By "real world" you mean custom enterprise programming? Sorry, Python is only good if you evrybody on the team is competent, so the PHBs won't ever like it. Thus, no, most jobs will stay at Java/.Net.
Now, for the people that are out of that segment - like, you know, the people that CREATE most things out there - it is a real alternative that must be weighted against the others. The thing is, if you create something, that thing didn't come in your job description.
Rethinking email
It gets no new features and only security bug fixes. It's obvious they're only supporting it to not piss off people not that they intend for it to live forever along side python 3.
Atleast better than .ps1-files (powershell scripts) which is named ".ps1" for all released versions, 1.0, 2.0 and 3.0.
Sony might have objected had PowerShell scripts been named with the interpreter version in the manner that you appear to imply. PS2, for example, was taken twice: one by an IBM PC model that introduced the keyboard and mouse connector used for years before USB, and once by a game console.
I thought Word was a program for communication among Ghetto slangsters.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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
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
Do tell that to Google, I'm sure they'll stop using it right away when they hear it's not a real language.
-- Lattyware (www.lattyware.co.uk)
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.
Can I have some of what you are smoking?
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
It is!
It should be obvious even by looking at the box.
"Google hasn't used Python for anything in years" is a bit of a stretch, but it's no secret that Google really only uses Python for their legacy apps these days.
All those cherries ended up in the CherryPy.
Python 3 is not really a different language than Python 2. Yes, there are some backward incompatibilities, but I think their impact on Python programmers has been way overblown. Through experience, most of us doing primarily Python 3 work know that it is usually rather easy to write code that works in both Python 2 and Python 3. If the code has a very clear model of what are byte and what are strings (the hardest part about porting, which Python 2 let you be sloppy about), then it is generally very easy to port to Python 3 or add Python 3 support. Once you start writing the bulk of your code in Python 3, Python 2 just seems like an increasingly creaky old version. :) The new features in Python 3.3 are amazing.
Python 2.7 will live on for a long time, officially much longer than the normal Python version lifetime. If you must continue to use Python 2, please do! But I think it will become increasingly clear that Python 3 has so many advantages, it only makes sense to switch to it.
Guido was always very clear in his thinking that a widespread transition to Python 3 would take 5 years, and given that Python 3.0 was released in December 2008, I think we're on just the right path for Python 3.
-Barry
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.
The launcher is added with 3.3
Thank you. Side-by-side on Windows was broken in 3.0, 3.1, and 3.2, but now that it appears fixed, one more obstacle to adoption of Python 3.3 is out of the way.
Actually GIMP 2.8.2 is quite good. I work with it almost daily.
Agreed. Science stuff works great (including matplotlib)
Is anything major using Python 3 already?
Guess it depends on your measurement. Blender uses (hosts) Python 3 for scripting.
Don't say always. At some point Python2 will be deprecated. Possibly not for 5 years or more, but at some point. It has been announced that python2.7 will be the last release of the Python2 series. Well, they may change their minds, and go to python2.8, but that's not the current plan.
So Python2 is stable, and will endure for quite awhile. But not forever. If you're planning for the next decade, you should use Python3. Don't plan for longer. C might be stable in that long a run, but don't count on it.
I think we've pushed this "anyone can grow up to be president" thing too far.
Suddenly python pops up? Lol. I bet you can't code for shit.
Python 2.7 is not going anywhere in Ubuntu. If you want to continue to use it, please do!
The movement toward Python 3 in Ubuntu will be mostly transparent to users. Users generally don't care what language their desktop applications are written in, so the fact that some will now be in Python 3 instead of Python 2 should have no effect on them, except perhaps the *lack* of dreaded UnicodeErrors in non-English locales, since we can now take advantage of Python 3's clear distinction between bytes and strings (unlike in Python 2).
Most libraries will continue to be available for Python 2, but now they will also be available for Python 3, if you want it. An example is dbus. You can write dbus clients and servers in either Python 2 or 3, and this goes for more libraries (and growing).
I agree that there are still many libraries that need porting. An example is Xapian (which turns out to be a tough one, more due to SWIG and C++ than Python 3). oauth is another one because the most popular Python oauth library has been abandoned upstream for ages. Big frameworks like Twisted, Django, and Zope are getting there, but of course, the higher up the food chain you go, the longer it will take to port.
-Barry
You're thinking of people's opinion of you when you try to be witty.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
Took me a while, but brilliant!
If that's the case, then why do they employ Guido (and pay him for, essentially, just working on Python)?
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".
You mean like awk and bison I presume?
Unix having arbitrarily odd names for programs and commands is not new.
- Michael T. Babcock (Yes, I blog)
I don't understand, I suspect you have a LISP.
- Michael T. Babcock (Yes, I blog)
There sure are a lot of posts here declaring what various people think "went wrong" with python 3. I find it pretty funny that each post describes a different perceived problem, yet reveals a similarly self-absorbed view, and in many cases a presumption that the 2-to-3 transition should have been universally complete by now. Folks, consider this: A project might not actually be a failure just because it's different from whatever you're used to.
He does have a point. I love Red Hat and derivatives, I program daily in Python, but you can call yum anything but speedy.
8 of 13 people found this answer helpful. Did you?
True, but if you use 0install then you can specify the version you want in the metadata, e.g.
... etc.
<command name='run' path='myprog.py'>
<runner interface='http://repo.roscidus.com/python/python'>
<version not-before='2.6' before='3'/>
</runner>
</command>
will select Python 2.6 or 2.7 on Debian, Ubuntu, Fedora, OpenSUSE, Arch, Windows, MacOS X,
(example taken from the docs at http://0install.net/local-feeds.html)
No. He doesn't have a point since the bottlenecks are in the downloads and in the rpm installs. Rpm is written in C, and the I/O part has nothing to do with yum either.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Well, I remember yum hitting 1 GB allocated memory on RedHat 5 when updating. The lead developer told me that he couldn't do anything about that, it was just the size of the repository.
Yum is not bad, but far from a Python poster child.
8 of 13 people found this answer helpful. Did you?
This would actually speed it up, not slow it down if I understand what you are saying, since the contents of the repo are resident in RAM rather than on the disk, thereby removing a significant bottleneck. OTOH, I see your point that if the guy really thought nothing could be done about that issue, then he probably is pretty clueless about python in general, and how to use it in an optimal way specifically.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Try to follow along. The discussion is about complaining that yum is slow, and claiming that it is because Python is slow.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
What's wrong with .sh for your Python programs?
The fact that I'd have to replace Windows Explorer on end users' Windows PCs with a UNIX style shell. This was a problem until Python 3.3, which associates .py files with a limited shebang interpreter as AC mentioned.
Whether you can handle your own memory management or not depends on what you are doing. In relatively small applications it's no problem. Start getting larger, and you can't tell which processes are using, or going to use, which pieces of memory. It does, however, place constraints on what lower level operations are allowed. But so does parallel processing in general, even if it's small enough that you CAN manually handle memory allocation.
FWIW, even algorithmic garbage collectors run into problems when one is processing multiple streams of instructions, which is why so many languages are currently stressing immutable or final data allocation. That way data can safely be copied from place to place. But for this to be possible, any included pointers MUST be managed by the language, not by the programmer.
OTOH, for small programs, garbage collection does slow everything down, so in that context you have a good point. But that's not the entire context that computer languages need to handle.
Am I recommending that C adopt mandatory garbage collection? No. But I am recommending that it be built into the language. It could be a compile-time option, which, if enabled, would forbid certain kinds of activity (casting pointers back and forth to integers, etc.), and allow the compiler that handle the allocation and freeing of memory. This allows one to be maximally efficient when that's what's needed.
OTOH, I can see an argument that C should remain closer to the metal. But it's been moving away from that for a very long time. Still...perhaps it's best that one major language keep as much purity (in the sense of close to the metal) as reasonable. But do note that this is an argument against including even ASCII string literals in the language, and realize that you don't really want to be as pure as possible, or you'd be using assembler, and not even a macro-assembler. (I suppose that since there's memory mapping hardware that these days relocatable assembler code *is* close to the metal. Once it wasn't.)
I think we've pushed this "anyone can grow up to be president" thing too far.
When starting a new project, please select a name that isn't already in common use. It's so much easier to google.