Guido and Bruce Eckel Discuss Python 3000 305
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."
Bruce, Just a Make a New Language Then (Score:2, Interesting)
staying with an old version -- how? (Score:5, Interesting)
losing the print statement (Score:4, Interesting)
I also think, more generally, that people are in for a world of pain, converting to python 3000. There needs to be tools that are %100 reliable that can convert code from 2.6->3.0. Otherwise, there will just be too much code mass, and it will take a long long time for 3.0 to be accepted. Such a stall is bad news for an OSS project.
Simon.
Re:documentation (Score:5, Interesting)
Huh. One of the things that really attracted me to Python was the (perceived) quality of the Web documentation. The Python Tutorial [python.org] and Python Reference Manual [python.org] are very complete and provide an excellent high-level overview of the language, something which can be rather difficult to come across in, for example, the land of Perl. Granted, the Library Reference [python.org] could be stronger, but I can still usually find what I need in there; and if not, it's easy enough to invoke dir() and view the __doc__ string on any objects of interest from Python's command line.
I guess it's just a matter of personal taste. But for what it's worth, I found it much easer to pick up Python without resorting to any third-party books or reference materials than to start fresh with either Ruby or Perl.
Re:Sounds familiar. (Score:5, Interesting)
So why does Python scatter its standard libraries across half a dozen packages? Probably one of the biggest problems beginners have with Python is that they can never remember whether something is in os, os.path, sys, string, re, or whether it's maybe just a method on an object, or maybe it changed in some recent release. And you can't just safely import everything from those packages either.
They are both wrong! (Score:2, Interesting)
Compiled type-safe python (Score:4, Interesting)
However, it could be done like this. First recognize that nearly all uses of python do not take any advantage of the dynamic typing, and nearly all calls to functions happen with arguments whose type is not varying. Thus why not have a mechanism, an optional one, that could hint at the expected typing for a function and its args. I realize there are ways with "decorators" to add type checking, but that's not the point. I'm talking about type hinting. The reason for this would be to allow a compiler to examine the code, read the hints, and then compile the code or translate it to C++.
The problem with existing python accelerators is that they bend overbackwards to avoid stepping on the dynamic typing. Why not allow the user to forego that if they want to and have static typing if they want to go to the effort of indicating it.
Regarding GUI (Score:4, Interesting)
This is a language, so keep it as such. I realize it's hard to market a language without a rich set of standardized libraries, but the UI should be an exception. This is an area where the technology is slowly but constantly changing. In addition, GUIs tend to have somewhat "religious" supporters. Also, as Bruce mentioned, all of the toolkits have their advantages and disadvantages. One "disadvantage" they all share is a changing API. Nothing stays the same forever. Tying your language standard to a third party API is problematic.
One language tried to do this (Java), but it's original GUI was universally reviled, and it's current "official" GUI (Swing) is competing with an extremely popular third party solution (SWT), and another third party solution (Jambi) is starting to gain enthusiastic users.
So in my opinion, leave the UI unstandardized.
Re:Strange Guido's reply (Score:5, Interesting)
The problem is that Python does not distinguish between creating a variable and assigning a new value to an existing variable. This means that scoping doesn't work as well as it should. In particular, you can't do this: because Python cannot tell that the second v is the same as the first. You can access v from the Child() function, but you can't update it. There are ways around this problem, but they are ugly. That's why Python really uses self: so it knows which scope each variable belongs to. And it's a pain. There should be a way to explicitly specify the scope of variables without having to resort to ugly hacks. I am a big fan of Python, but it could be so much better...
Re:Solved problems (Score:5, Interesting)
Personally, I like some of the ideas of Python better than Haskell and Erlang. There have been some very good ways of doing multithreading, even massive multithreading (see Stackless, some of which is now back in the main Python), and making it natural, even with an imperative style of programming. Some implementations (again, see Stackless) make threads so lightweight that you can spawn thousands without being concerned about performance, and the structures used make it natural to do that without any kind of locking issues -- sometimes, without explicit locks at all.
The problem is not with python, the language. It's with python, the interpreter, and all the associated C modules, embedded versions, etc, not to mention Python programs that might assume the same behavior.
Specifically, it's the Global Interpreter Lock. The GIL is the most retarded move I've ever seen in a language. Basically, Python said "We don't want to make the Python interpreter too complicated, so we're going to deliberately remove multicore support." They even support real OS threads, but only one Python instruction may be executed at a time. Which is fucking stupid.
There are a lot of really good things in Python. I'd like to be able to write a good, modern game with Python, but if you figure it may be half as fast as C already, I'm not going to lose another 50% speed because it can't use both cores. (Yes, psyco can make it MUCH faster, close to C. But, psyco doesn't work on 64-bit, which is another kick in the balls for performance.)
Re:Syntactic whitespace (Score:4, Interesting)
If anyone is interested, my top candidates for improvement or python would be:
* regular {} blocks instead of semantic whitespace
* non-trivial lambda-statements
* explicit scoping of variables like with the "var"-keyword in Javascript
Nice to have but not essential would be:
* ++ and its friends
* ternary statements
* switch statements, preferably supporting strings. I know that you can simulate this with a dict and a try-catch but honestly, why keep a feature out of the language for "simplicity" and then encourage people to use horribly unreadable workarounds?
Re:Those aren't the real problems with Python (Score:3, Interesting)
* Multicore support is a nonissue. CPython is too slow to need it.
Agreed, but CPython isn't the only implementation that has problems with multicore support. The psyco JIT compiler also has a global lock, and is fast enough for many compute intensive applications. But still doesn't benefit from multicores. The issue is that dictionaries and lists are expected to have atomic operations, which is rather slow in most cases without the global lock. This needs changing at a language definition level, perhaps by introducing a way to declare that this isn't necessary.
Re:Those aren't the real problems with Python (Score:4, Interesting)
It is actually two issues.
First is Psyco, and any similar efforts in the future. Psyco, aside from not supporting anything but 32-bit x86, also is limited to a single core, despite being very, very fast -- in some cases, supposedly faster than C. In any case, that is the goal.
And if CPython is that slow, I'll take any performance boost I can get.
Second, it means that any other implementation that doesn't have a GIL is likely going to expose obscure bugs in existing python programs. Well, not bugs, but assumptions that only one Python instruction can run at a time. Not to mention the C extensions...
Well, first, no compiler is "easy". If it is, write me a C compiler that's half as good as gcc.
Second, it's been done. You mention LISP:
And yet today, there are very fast and useful LISP compilers, which do just what you said an "optimizing compiler" can't do -- they make LISP fast enough that it could probably be used as a replacement for C or Java (for most things), if it weren't for all those damned parentheses...
Well, CPAN is better than just about any language. Also, you were expecting to find cheese in the Cheese Shop? They're all out of that!
In any case, CPAN doesn't seem to be much better supported -- often, yes, a developer or two, working in isolation, maybe a bit of peer review.
Also, this is like the argument of Windows being better than Linux, due to number of apps. It's a sad reality that it limits options, but in my experience, Linux is better enough that I'd often rather do a little extra work to make Linux do what I want than buy a Windows program to do the same thing.
I don't think Python is quite there yet, though. Notice how pretty much every one of your Python complaints holds for Perl, except CPAN. But, if Python were fast enough, and had threading that worked, I'd be using it instead of Perl, no question. (For that matter, if Perl6 ever gets released, and if Python gets ported to Parrot -- not very likely, I know, but if it happened -- CPAN would suddenly become available to Python people.)
Which would be great, if it weren't for the fucking GIL. I hate that thing.
Then again, people are willing to deploy Ruby, so at a certain point, CPU is cheaper than programmers. Although I still wish I didn't have to choose.
Well, Perl hasn't replaced Java, and Java hasn't replaced C.
Frankly, I think one of these languages needs to step up and offer something compelling -- or I need to find the one that already has, and still isn't dominating. But I've been looking for years, and still haven't found something that's as dynamic and easy as perl/python/ruby, as portable as Java (even CORA, please), and as fast as C, even though I'm convinced it's possible.