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
I think you just accidentally a word
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.
hah, Perl 6 is stillborn and it isn't even done being pushed out of Larry's pussy yet.
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.
I extensively use Numpy at work, and that was the primary reason Python 3 was useless to me. However, I should mention that as of Numpy 1.5 release some months ago, Python 3 is now supported. The FAQ page on the Numpy website just hasn't been updated properly.
And Scipy 0.9.0 *does* support Python 3.1. It's currently at release candidate 5, i.e. within a few weeks of an official release. See the release notes from yesterday.
PyLab, I'm not certain about. Matplotlib has an initial port but I think it's not really working yet.
I think now that Numpy and Scipy are running on Python 3.x you'll see a lot more interest in people running it who do real stuff with Python.
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.
But... but... I just bought a special unicode keyboard just so I could write code that could never be posted on slashdot!
If I have been able to see further than others, it is because I bought a pair of binoculars.
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.
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
A lot of python 2 libs won't have too much trouble running under 3 without modifications.
Silly rabbit
Sorry, but there are still lots of libraries that haven't been ported yet, or the ports that exist are unreasonably buggy.
Sorry, if this offends you, but it's the truth.
OTOH, why would you expect them to already have been ported? It's a process. And early versions often have lots of bugs. There's a lot more now than there were six months ago, there'll be more in another six months. And in a year Python3 will be the default environment. (Naturally, all times are rough estimates.)
But I do wish that they included a simple B+Tree system that was Pythonic. Databases are all very well, but frequently I just want to deal with really large tables of data that should be stored in a file, but with random access. Databases aren't a good match. Even BSDDB isn't a good choice. I often want to use an integer key, and BSDDB converts it to a string, which isn't what I want. And I really don't want the overhead of SQL. I want to handle the logic in Python. (I don't even know if it's usually possible in SQL, but it might be a Turing complete language, so it might be possible. Just unreasonable.)
I think we've pushed this "anyone can grow up to be president" thing too far.
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?
What's the white space issue?
If you mean the fact it allows mixed tabs and spaces, warning can be issues by the -t command line flag for a long time now in 2.x...
From the top of my head:
- Fixed inconsistencies between the language and functions (print, exec, execfile).
- Obsoleted a ton of legacy code.
- Made a clear cut between the abstract concept of string (internally Unicode) and an array of bytes.
- Better multi-threading support.
^_^
Numpy seems to support Python3
Just check Wikipedia, with a link to http://sourceforge.net/projects/numpy/files/NumPy/1.5.0/NOTES.txt/download
You can also find the announcement from last July : http://mail.scipy.org/pipermail/numpy-discussion/2010-July/051436.html
I posted my honest opinion. That is not trolling. Unlike you, I did not have a hysterical hissy-fit.
If you mean the fact it allows mixed tabs and spaces, warning can be issues by the -t command line flag for a long time now in 2.x...
But there is no standard. If I get somebody's else's python code, I don't what I'm looking at, unless I do a hex dump or something.
White space also causes problems with emailing code, or cutting and pasting code.
These, very serious, problems, have been around for a long time. Since 3.x is throwing away backward compatibility anyway, this would have been a golden opportunity to fix these, long standing, design flaws. For example, they could have disallowed tabs, and required four spaces. I think Guido himself recommends four spaces.
BTW: I think you know that I am not the only person who feels this way about python. It's a good language, in many respects. But, like many python users, I am frustrated by these design issues.
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.