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."

Bad link?

[albalbo]

First link should probably be to http://www.artima.com/forums/flat.jsp?forum=106&thread=214112 [artima.com] .

Re:staying with an old version -- how?

[Niten]

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.

Re:documentation

[Waffle Iron]

Does anyone know of a site with ALL the info, that lists ALL the methods in ALL the classes along with what those methods are expecting?

/usr/share/doc/python/html/lib/lib.html

It's not the langauge, stupid

[Aminion]

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.

Re:Blow my mind.

[slashnot007]

Your wish is granted already. import numpy

Yeah, well

[stonecypher]

Bruce Eckel is looking for Erlang. That's not what Python is for.

Re:Compiled Python 3000?

[Just Some Guy]

I love Python, but it's often just too slow!

Try this, in increasing order of work required (and likely reward).

One: try Psyco [sourceforge.net]. 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 [python.org]. Basically, let Python do the work for you by handing off as much processing as possible to the language. For example, this:

output = []
for value in input: output.append(transformfunc(value))

is longer to type and possibly vastly longer to execute than:

output = [transformfunc(value) for value in input]

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 [python.org]. 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.

Re:Python++?

[StarfishOne]

I'd say there's nothing wrong with Python += 1

Am I the only one that noted this?

[Anonymous Coward]

The first link points to the same page as the second link. It should point to this [artima.com]

Ok, this is Slashdot, no one clicks those links anyway.

Re:Solved problems

[ubernostrum]

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.

Re:Bruce, Just a Make a New Language Then

[Anonymous Coward]

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.

Re:Those aren't the real problems with Python

[Wheat]

> 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.

Re:staying with an old version -- how?

[Wheat]

> 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.

Re:losing the print statement

[Nosklo]

you can't just type "map(print, listname)" or anything else as compact and "clean".

And in Python 3k you won't be able to do that either, because Map now returns an iterator object [python.org] and that would result in no function actually being called unless the iterator is used. One good solution would be to:

[print(line) for line in listname]