Slashdot Mirror
Guido and Bruce Eckel Discuss Python 3000
Phoe6 writes "Leading author and programmer, Bruce Eckel, posted some of his concerns on Python 3000 stating that the Python community is failing to address some of the important issues with this major, backward incompatible release. Problems he mentions are concurrency support on multi-core CPUs, easy deployment support, and a standardized user interface, amongst others. He expresses his dissatisfaction at the post titled "Python 3K or Python 2.9?. Guido van Rossum addresses the concerns in a very pragmatic way with his response to Bruce Eckel and calls for more developers to contribute to Python to improve it further. Bruce Eckel concludes with his thoughts that he wants his favorite language to be better with his reply to Guido's reply."
First link should probably be to http://www.artima.com/forums/flat.jsp?forum=106&thread=214112 .
"Elmo knows where you live!" - The Simpsons
You'd typically install multiple versions of python on the same machine. On Unix-like systems each Python version's executable will be named in the manner of python2.4, python2.5, and so on, with a symbolic link from /path/python to (usually) the newest version. Scripts can call for a specific version of Python by starting with a hash-bang line like #!/usr/bin/env python2.5.
Many operating systems facilitate this scheme by offering independent packages for different versions of Python. In particular, on Debian Etch the user can choose to install any of the python2.3, python2.4, and python2.5 packages, then use update-alternatives(8) to switch the system default between the three.
The Python Software Foundation (PSF) needs to realize that there's so much more to a language than the syntax. There needs to be a major effort in making it easier to install, get started with, and deploy Python, and much more advocating and marketing needs to be done. For example, PSF should start campaigning so that web hosting providers support Python out of the box. Why do you think PHP, despite it's obvious drawbacks, is so popular? Because it's ubiquitously supported and requires nil efforts to get started!
It's great that Python is constantly evolving into a cleaner and more competent language, but I fear that the Python 3000 efforts could result in a pyrrhic victory in the war between programming languages because it simply fails to attract enough new people. There's so much that the PSF could do, but there seems to be too much "But that's not our job!"-thinking.
Your wish is granted already. import numpy
Bruce Eckel is looking for Erlang. That's not what Python is for.
StoneCypher is Full of BS
Try this, in increasing order of work required (and likely reward).
One: try Psyco. It may give you the bump you needed, or it may do nothing, but since it's so easy you might as well try it.
Two: write faster code. Basically, let Python do the work for you by handing off as much processing as possible to the language. For example, this:
is longer to type and possibly vastly longer to execute than:
since the latter knows how many values it needs to pre-allocate memory for, and can perform the operations in a tight C loop instead of evaluating a much slower Python loop.
Three: profile. Once you're sure that you've written good algorithms are aren't re-implementing large bits of Python in Python, run a profiler to find out where you can direct extra attention. Some people do this before #2, but I don't touch it until I know that everything else is right.
I wrote a "diff" function in native Python that searches two many-gig files for lines that appear in one but not the other. Said function is IO bound on a SCSI-320 RAID-0 system with 4 15K RPM drives, and typically uses about 20% CPU for the duration. You can write slow Python, but that doesn't mean that you have to.
Dewey, what part of this looks like authorities should be involved?
I'd say there's nothing wrong with Python += 1
The first link points to the same page as the second link. It should point to this
Ok, this is Slashdot, no one clicks those links anyway.
Er. Image rendering is typically one of the most obvious places where separate processes with no shared state yield huge benefits. In fact, image/graphics rendering applications are among the few categories of software which are able to take full advantage of multi-core systems right now, and it's largely because this is such a good solution for them.
You don't just fork a language, for all sorts of mostly political reasons. Using a different language is certainly an option -- these days it's not even unreasonable to bundle the entire language interpreter along with your program. Perhaps if Ruby 2.0 ever happens, there will be some additional pressure on python to improve, but right now the competition isn't there. Sure as hell ain't Perl 6.
Guido has himself said that he'll accept patches that remove the Global Interpreter Lock, IF they don't hurt performance AND they don't overly complicate the C API. I don't think that's too unreasonable.
> I suppose doing stuff like that is hard and boring for most people. So they'd rather do stuff like come out with python3k or perl6 instead of a fast python2.x/perl5.
No. Please read the article(s), it is inaccurate to compare Python 3 development with Perl 6 development. Bruce Eckel was whinging about Python 3 not doing enough "fun stuff" as Python 3 is really only concerned with removing warts that resulted from early design decisions in Python. Perl 6 is about doing "fun stuff". As for performance, the cPython implementation in Python 2 has had a lot of optimization work done to it. Much optimization work done to Python 3 will be available to Python 2 in the form of the Python 2.6 release.
> Wow, they break compatibility with every dot release? That sounds crazy to me
That would indeed be crazy. Python has not had any significant breaks in backwards compatability since I started using it in 1999. You can run a Python 1.5 or Python 2.0 program just fine in a Python 2.5 program. Of course, if you are taking advantage of a language feature introduced in Python 2.5 of course you can't run it in a earlier release.
There are a few exceptions, such as code that interfaces with C has had changes. But Python developers have put a lot of time and effort into maintaining backwards compatability. This is the point of breaking backwards compatability in Python 3, and the current Python 2.5 implementation has a lot of verbose, length code that deals with a lot of corner cases that almost no one uses. Python 3 is about fixing all those small things that you can't fix without breaking backwards compatability, and about ditching all that backwards compatablity that is in Python 2 that makes maintainence and optimization that much harder.
find -name "*base*" -exec chown us {} \; ; ln -s