Slashdot Mirror
Python 3.2 Released
digitalderbs writes "Python 3.2 was released on Feb 20th 2011 with many new improvements. New features include many useful updates to the unittest module, a stable ABI for extensions, pyc repository directories, improvements to the email and ssl modules and many others. This also marks the first release in the 3000-series that is no longer backported to the 2.0-series."
That no one will use because there is no compelling reason to port all that cool stuff developed for the 2.x series.
Come on, guys. How does this help us keep up to date on political events, popular music, or funny videos?
Is the GIL removed from the interpreter ?
Jehovah be praised, Oracle was not selected
I don't know of a major Python library that isn't upgrading to Py3 - and this release marks the tipping point where we wave goodbye to the aging 2.x codebase.
PEP-3003, the moratorium to changes to the language to allow alternative Python implementations to catch up, only applies up to the 3.2 series so we're going to continue moving forward from here. Nobody's forcing Python 2 users to upgrade their code, but there's many advantages and ever decreases hurdles to doing so.
Don't fear change, this change is good and necessary for the advancement of the language.
Have they added Anti-Gravity yet?
Summation 2
Python? People are still using that? Perl is the past, present and future.
You can spew lots of warnings.. but to me breaking backwards compatibility in a _programming language_ is sloppy and completely unacceptable.
So that's there are so many goddamn programming languages with similar syntax!
The only libraries or frameworks that don't support Python 3 yet are those that are dead, and some web frameworks.
Those web frameworks get a lot of hype on the web, but they represent an extremely small segment of the Python-using community. Like most things web-related, they're still far behind the times. Meanwhile, the rest of us have been happily using Python 3 since it was released a few years ago.
I don't understand how this Py3k praising always gets such good moderation on /.
Python 3 has left the original focus of the language as something simple and easy to use. All the changes are towards a MORE COMPLEX language, I see no change that makes it simpler to use, no change that requires less code than the former version.
Py3k is moving in the direction of Java, where nothing can be done without typing a hundred lines of code. An example from the Python documentation:
17.1.3.1. Replacing /bin/sh shell backquote
output=`mycmd myarg`
==>
output = Popen(["mycmd", "myarg"], stdout=PIPE).communicate()[0]
I cannot see how would anyone call this an "improvement"... Oh, sure, it gives me more options, more control, but if I had wanted to finely tune the innards of the program I would have used C++.
This is my biggest complaint with python (I have others, I'll admit I have little love for python). This is not the way to develop a language.
The problem with endless back-porting is that it stagnates any âoerevolutionaryâ development of the language. There are certain âoemilestonesâ where it makes sense to completely walk away from the old ways of doing something and move on. At a certain point, back-porting makes everything âoehalf-bakedâ.
If you want news from today, you have to come back tomorrow.
brings a different context to the the phrase "blow jobs"
(1.21 gigawatts) / (88 miles per hour) = 30 757 874 newtons
How can a stable ABI be described as "new?" Hey guys, it's stable! And it has been stable for 24 hours!
In other news, I quit smoking! I haven't had one since last night right before I went to bed.
PIL is working on Python 3; "The current free version is PIL 1.1.7. This release supports Python 1.5.2 and newer, including 2.5 and 2.6. A version for 3.X will be released later" (source). So is Django, Turbogears, wxpython, pygtk, etc. You can vote on which major 3rd party packages you'd like to see ported.
PyQT, CherryPy, Genshi, and many others are already ported to Python 3.
hope that you can find a compatible version years down the road that you can give to your clients.
Yes, its known as downloading and/or compiling. Dumbass.
Unless your clients are trying to use your product on shared hosting, where they don't have the privilege to compile their own software. A dedicated server would cost far more per month.
There is NO breaking of backwards compatibility in the Python 2 Language.
And there is NO breaking of backwards compatibility in the Python 3 Language.
And there is NO shared web host offering the Python 3 Language that I could find in a few minutes of Googling (e.g. python 3 shared web hosting). .py files in the Python 2 Language and .py files in the Python 3 Language associated with respective programs in the Windows Operating System on end users' computers, unlike *n?x which has #!/usr/bin/env python2.7.
And there is NO easy way to keep both
If they had named it Bathiola, would you be complaining that the made it too similar to Python?
No. If Python 3 were called Bathiola, it wouldn't have had the .py extension, and the file manager would successfully choose to run double-clicked .py programs in Python and double-clicked .bath programs in Bathiola. And it'd be easier to separate out web hosts offering Bathiola from web hosts offering only Python (e.g. Google bathiola web hosting in this alternate universe).
if they had called the language by a new name, wouldn't that nullify the objection?
In fact it would; see my reply to maxume.
Think of Python3 as a new (though not particularly ground-breaking) language which happens to be very Python2-like
And which has a name confusingly similar to that of Python 2. And which uses the same file name extension as Python 2. And which takes web hosting services that currently offer Python 2 far longer to adopt. Many of the same arguments were tossed around when someone proposed calling the successor to Visual Basic 6 by the name Visual Fred.
#smalldick
I don't know of a major Python library that isn't upgrading to Py3 - and this release marks the tipping point where we wave goodbye to the aging 2.x codebase.
Ah, denial. Some major modules that aren't making the transition:
And those are just ones I happen to have used.
Because the Python community is so tiny, there are major modules that are maintained by only one person. In many cases, they've moved on to other things, and no one is maintaining the modules. The major changes required to move to Python 3.x are non-trivial and aren't being done, because someone would have to take responsibility for a big module they didn't write to do the conversion. In some cases, there are newer, completely different modules with different APIs that perform the old functions. So end users have to do a major rewrite on production programs just to stay in the same place. It's a huge transition. Guido has this smoke-and-mirrors pitch claiming that it's "done". That's because the Python organization, such as it is, disclaims all responsibility for getting modules ported. So it's not his problem that it sucks.
None of the non-CPython implementations are making the transition. Not IronPython (abandoned by Microsoft). Not Shed Skin (only one developer). Not PyPy (defunded by the European Union). Not even Google's own Unladen Swallow is moving to Python 2.6, (Google seems to have abandoned Unladen Swallow after discovering that Guido's insistence on excessively dynamic features meant a JIT compiler didn't speed it up much.) The transition to Python 3 has thus killed all other Python projects.
CPython is a naive interpreter, roughly 60x slower than C. It's been stuck at that speed for a decade. And now, that's all we have left.
If you're using Python for anything important, start working on your exit strategy.
So consider Python 2.0 as a legacy language then, and Python 3.0 as a new one.
That'd be great if I could have both languages installed side-by-side on Windows, or on Ubuntu without having to compile from source, or on a shared hosting provider.
IMO: 3.x is a stupid "upgrade. "
Many things were changed, that nobody wanted changed. Major problems, such as the white space issue are not fixed.
3.x gave the core developers an opportunity, a mile wide, to fix python's worst design flaws. But they ignored those flaws, and did what they wanted to do, which serves no purpose.
The core developers are designing a language for themselves, and nobody else.
Finding such shared hosts today is trivially easy and is becoming easier every day
I put python 3 web hosting into Google and the first few results didn't appear very relevant. What keywords did I miss?
There's a little bit of revisionist history going on in your post but I don't get the impression that's by intent.
Ah, denial. Some major modules that aren't making the transition:
That was a silly thing for him to say. Clearly some modules are not actively being ported. That, however, doesn't mean they won't or can't.
The major changes required to move to Python 3.x are non-trivial and aren't being done
Very much over stating the difficulty. There has already been a number of porting sprints. In a number of cases, rather large frameworks have been ported over a weekend. By in large, the porting effort actually is extremely trivial and frequently, the automated tools can complete 90-95% of the port by themselves. Really, the ports which tend to be problematic are the ones with large, legacy code bases. These are non-trivial not because of their size, but because of the porting effort in of themselves is a function of line count.
In some cases, there are newer, completely different modules with different APIs that perform the old functions. So end users have to do a major rewrite on production programs just to stay in the same place.
Could you be more specific. I'm actually drawing a blank here. Its true some functions/classes have been moved to other packages. Most of the time its as simple as changing an import or a namespace prefix associated with a function call. Again, most of the tedium is addressed by means of the automated porting tools. And if you do have examples, please offer up why such an example affects such a wide breath of existing code its more than a corner case.
It's a huge transition.
Again, you're way overstating the problem.
Guido has this smoke-and-mirrors pitch claiming that it's "done". That's because the Python organization, such as it is, disclaims all responsibility for getting modules ported. So it's not his problem that it sucks.
Trollish and red herring in nature. Not really applicable to the discussion at hand. So now Guido is responsible for all python code which has ever been written. Such a statement is silliness at best.
None of the non-CPython implementations are making the transition.
This has what to do with anything? And how many dozens of people really care?
Not IronPython (abandoned by Microsoft).
So now a port of python that no one used is a significant weight preventing the adoption of the latest python release? Completely rediculas. If anything, it further underscores the stupidity of IronPython and MS' mind-share-gimick-marketing rather than serving as a detracting for python migration. Bluntly, I'm sure IronPython's three users are really upset that they made such woefully bad decisions to adopt IronPython (contrary to the rest of the world's warnings and MS' very long associated history).
Not Shed Skin (only one developer).
That's because he's one developer and doesn't have the man power. Its not that he won't, rather, its that he is simply one man. Furthermore, Shed Skin is a niche product. Its neat and all, but it has a long way to go before, frankly, anyone other than that one developer really gives a crap about it. Don't get me wrong, its a cool tool, but I won't use it for production. Hell, most python developers don't even know about it. And when they do, they tend to think of it as an experimental toy. Seemingly, the author sees it this way too. So again, not a detractor for Python 3.x in the least. You're being silly.
Not even Google's own Unladen Swallow is moving to Python 2.6, (Google seems to have abandoned Unladen Swallow after discovering that Guido's insistence on excessively dynamic features meant a JIT compiler didn't speed it up much.)
Completely wrong and extremely trollish in nature. Unladen Swal
Completely wrong and extremely trollish in nature. Unladen Swallow (US) is a dead project because other projects have already exceeded US' goals.
Here's what the developers of Unladen Swallow had to say::
Hi Arek, On Mon, Nov 8, 2010 at 1:10 AM, Arek StefaÅski wrote: :
> Hey, I thought Unladen Swallow is dead.
> Sure seems close to this.
> It's really cool project, why is it so 'abandoned' right now?
Jeffrey and I have been pulled on to other projects of higher importance to Google. Unfortunately, no-one from the Python open-source community has been interested in picking up the merger work, and since none of the original team is still full-time on the project, it's moving very slowly. Finishing up the merger into the py3k-jit branch is a high priority for me this quarter, but what happens then is an open question.
Collin Winter
Doesn't sound like "because other projects have exceeded US goals", does it?
let's take a look at the "major" changes in 3.2: .pyc, .so stuff: only really relevant to developers of python itself, not programmers who program in python
- stable ABI,
- argparse: a nice update to optparse, but can easily be ported since it's just a module written in pure python. definitely not compelling enough of a reason to upgrade
- dictionary-based configuration for logging: again, not compelling at all when weighed against the syntax changes in py3k. also, just a module, can easily be back-ported.
- concurrency tools. there might be something interesting there
- wsgi, email library modules: looks like they are fixing things that were fouled up by the ascii->unicode switch. these are problems you would not have if you had stayed with python2
etc. etc. etc. Python3.{0,1,2} includes many things that would be nice additions to the language, but are totally not worth the headache. Think if all of those library authors had actually been enhancing their own libraries instead of rewriting the same features to fit into the py3k language changes. Take a look at PEP3000 and PEP3100. There really is no killer feature, nor do all the little upgrades collectively constitute a killer feature. It's just bad PR to cause so much work for the Python community for no discernible benefit.
Sure there are several things that "didn't quite make sense with python" but a lot of them were in libraries that could be deprecated and then removed. Or just deprecated. Successful languages don't change. The "purity" of the language is a bunch of ivory tower computer scientist BS that may very well tank the popularity of the language just as it was coming into its own. I hope they find a way to fix this that does not require everyone to just rewrite their python code to be py3k compatible. I know it's really not that much work, but again, there is no tangible reward for this effort.
When someone can point me to a real benefit that py3k brings that *could not* be achieved without the backward-compatibility break, then I will re-consider my position and even consider upgrading myself. Until then, I will be frustrated that the core dev team has caused busy work for everyone.
you mean pypy ?
3.x is a long way off for poeple who use Python for scientific computing, image processing, and pattern recognition, as it looks like numpy (and in turn scipy and matplotlib) isn't being supported in 3.x anytime soon:
http://new.scipy.org/faq.html#does-numpy-currently-work-with-python-3-x-what-about-scipy
Doesn't sound like "because other projects have exceeded US goals", does it?
The project was halted before they could start with some really good optimizations - which Pypy already does.. Go read the mailing lists. No one picked it up because other efforts had already progressed. Which raised the question, why continue US. Google dropped the project, thus killing it. Pypy has been far ahead of it for a while now. Why pick up US, which has a litany of issues (watch the video), when Pypy is already far, far ahead. The rest of what you said is what I said. There really isn't any deviation from what I said so I'm really no sure what you're picking at.
In short, my summation was completely accurate and well supported by lots of public videos and mailing list discussion.
> Ah, denial
Cool intro, bro!
> So it's not [Guido's] problem that [Python] sucks.
Were your parents eaten by Python or something? Calm it down a notch! Here's some facts about the projects that I know something about:
BeautifulSoup relied on HTMLParser, which relied on sgmllib. That could be overcome but the author, Leonard Richardson, doesn't enjoy working on BeautifulSoup:
He also notes that BeautifulSoup has been surpassed by other libraries, and recommends using those instead. It's no reflection on Python 3 that a library you used to use is not in active development.
I ported feedparser to Python 3 over the course of a week. It weren't no thang.
> If you're using Python for anything important, start working on your exit strategy.
I'm sorry Python made you cry, but I really do bristle that you hoisted up feedparser to support your sarcasm and hyperbole, particularly since you clearly have no idea what you're talking about in these three instances (and I think GooberToo handily dealt with some of your other points).
Informative post. Clearly underrated.
For what its worth, I get the feeling he's a full time troll. Some of his other posts are also very trollish and my response was somewhat troll moderated.