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
Shouldn't Python 3000 include a giant animated foot and silhouettes of the audience cracking jokes?
There's 2 sides to that, though.
While I agree, if he wants something that's fundamentally incompatible, but wants to still call it Python, that's silly.
On the other hand, they're saying 'We need more devs to work on Python' and pushing people away that -care- is exactly the opposite of that. If they want new devs, they'd better be resigned to the fact that the newcomers WILL have a different vision, just as this guy does. Finding code-slaves that will do everything you want exactly as it always has been is nearly impossible. You have to pay people to make them go through pain like that. (Coding in someone else's style is just as hard as painting in someone else's... Initially it's almost impossibly hard, and it gets easier with time... And there's always the alternative of working on something else without all that pain.)
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
One thing I don't understand about Eckel's original article is that he says breaking compatibility isn't a big deal, because the programmers who don't want to use the new version will just stay with the old one. How does that work for the users? Do they (a) end up having to pick which version of the language to install on their machine, and lose the ability to run half the world's python software, (b) have to install multiple versions of python on their machine, or (c) ??? Eckel is comparing with Java, but since Java is a compiled language, it's much less of an issue; syntactical changes don't affect the end user who just wants to run the code. How would python handle this? Perl 6, for instance, will automatically detect if the code you're running is perl 5, and will run it correctly in a compatibility mode.
Find free books.
My main problem with python 3.0 is the loss of the print statement! I have pestered Guido about it (including booing his talk on python3000 at europython this year) and, he said "well i brought this up last year and nobody seemed to object" and then to me personally "well no other language has a print statement".. I think the dumb simplicity of python's print statement is one of my favourite python things. It makes the language friendly (and I am a pepper-print debugger). As Mr. Hettinger says "you can't break 'hello world!'".
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.
Why not just call it Python++? Oh, that's right, Python doesn't do that.
You gotta find first gear in your giant robot car
Of course, since Python was named after Monty Python's Flying Circus, maybe it should be one of these:
Something along those lines anyway
The Digital Sorceress
A lot of what Eckel is saying is basically "Python should be more like other languages" - not because they're better, but because I'm more used to them. Obviously that's totally ridiculous, yet not surprising: If you look at his resume, it seems he's far more familiar with other languages than Python. I seriously doubt his credential - let alone objectiveness - to question Python's design.
Good point! Managing developers is hard enough in a company where the devs are paid. Managing volunteers is much, much harder. I strongly believe that half of the success of many open source projects is not the brilliant ideas or the super cool code, but the personality of the lead developer. Linus and Guido have proven to be such personalities that managed to galvanize hoards of developers around them. That is quite impressive. How many managers out there would be able retain employees without any pay?
One distinctive feature of these open source project leaders is that they have to act like assholes sometimes. I proves that they are tough, have a vision and won't budge. At first it seems counter-intuitive that being disagreeable will accomplish more but it works because even if it pushes one developer way, it might attract others or make the ones who are left work harder. It's like a medieval army. Decimating 1% of the army is worth it because it will make the other %99 percent work harder.
Huh. One of the things that really attracted me to Python was the (perceived) quality of the Web documentation. The Python Tutorial and Python Reference Manual 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 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.
That's not right; you need to name the language after a comedy troupe or show. Then famous bits from that can be used to name features or releases.
So, Bruce's Python derived language could be called SNL (Selfless Notation Language). Libraries could have names like "Bassomatic" (XML processing) or "Cowbell" (Multimedia types).
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Guido is right that Bruce's comments are mostly not core language issues.
But that's also the problem the Python language is fine the way it is; it doesn't need any major overhaul. Before hacking away on P3K, Guido should concentrate on getting things like the UI, the standard libraries, and package management straightened out. Community contributions won't fix those; in fact, community contributions are the source of many of the problems of Python because often, there are multiple, mutually incompatible libraries and tools trying to do the same thing and stepping on each other.
Guido is doing what is fun (hacking the language) instead of what is needed (straightening out the libraries), and that's not the best choice for Python overall.
Guido, always the pragmatist, and having just watched Reservoir Dogs, retorted that anyone who wants a modular language should get his head examined.
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.
Probably because the syntactic whitespace "problem" only exists in the heads of people who have never used Python.
Actually, those aren't the real problems with Python. They're not the ones that keep it from, say, replacing Perl.
Multicore support is a nonissue. CPython is too slow to need it. It's helpful to distinguish between the Python language, which isn't bad, and the CPython implementation, which is a slow, naive intepreter. CPython is about 60x slower than C. Compare Java, which, with modern just-in-time compilers, is about 2-3x slower than C. What's needed is a Python compiler with some smarts. There's Shed Skin, but it doesn't work yet.
One side effect of the speed problem is a tendency to try to write C modules to do things that take significant time. Unfortunately, CPython's interface to C is terrible, bug-prone, and changes with each new release.
The "dynamic language" thing is overdone. CPython is a demonstration of the fact that if you make everything a dictionary, it's easy to implement a dynamic language. It's also a demonstration of "if the only tool you have is a hammer, everything looks like a nail". Too much time is wasted in Python checking to see if something changed that probably didn't change. You can add or change functions or data of a running object or a running function. From outside the object or functionor thread, even! It's cool! It's l33t! It means you can't have an optimizing compiler. (Well, maybe you could, with one that goes to immense lengths to detect when "something funny" is going on and reworks the code on the fly. Won't be easy to implement.) Those features just don't get used that much, except to patch around bugs in the buggy Python libraries. The troubles with the "global interpreter lock" stem from this problem. The "global interpreter lock" is mostly protecting all those dictionaries which define the program. After all, one thread might want to patch the code in another thread.
Years ago, LISP hackers used to talk about how great it was that LISP programs could modify themselves while they were running. Few useful programs ever actually did so. Java has a certain amount of dynamism; you can, if you really have to, create Java code from within a program, compile it, and load it. Few programs need more dynamism than that. The Shed Skin implementation imposes some restrictions on dynamism, and they're on the right track.
Libraries are someone else's problem. Python is better than Perl as a language, but CPAN is better than Python's Cheese Shop. Many key modules aren't part of the main Python distribution and aren't synchronized with it. Examples are the interfaces to databases like MySQL and the interface to SSL. These lag months or years behind the base system. Modules outside the small "core" are not supported in any coherent way. Each is supported by a developer or two, working in isolation. If they lose interest, the module languishes, and nobody else can change it. This sometimes leads to multiple libraries for the same purpose, each with different bugs, and none good enough to obsolete the others.
The overall effect is that if you try to write something complicated in Python, everything goes along just great until you hit some library bug that can't easily be fixed. Or you discover that you need racks of servers to compensate for the painfully slow implementation.
That's why Python hasn't even replaced Perl, over fifteen years into the deployment of Python.
As long as they are going to break things here's my wish list for python. Make it possible for a compiler to compile it. Yes I realize that's essentially impossible for a dynamic language that does not enforce types in the function prototypes.
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.
Some drink at the fountain of knowledge. Others just gargle.
Regarding the GUI: don't.
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.
Don't blame me, I didn't vote for either of them!
He said that 'self == whitespace indentation' whereas for me I see that as exactly the oposite:
- using whitespace for indention remove 'visual noise' at the cost of 'language magic'
- using self adds 'visual noise' with the (dubious IMHO) benefit of language 'simplicity'.
IMHO removing self would be a big plus for Python, sure self makes things more explicit but if developers really wanted to use explicit language, they would stay with C instead of using Python, Ruby..
I'm even more perplexed why Guido is removing the "+" sign. HE says he's reserving it for an unnamed future use. In the mean time using two minus signs in a row is how all additions will be done in python 3000. I'm baffled by this.
It's not even an issue of better support for concurrency in the language itself.
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.)
Don't thank God, thank a doctor!
You do know about Python's block delimiter support, right? You can use the block delimiters from any language you like, just prefix them with '#' and Python will handle them automatically.
Sounds like some tough issues. Good thing they have 993 years to get it right.
Nope... I like python and use it every day. Losing the syntactic whitespace for a more traditional whitespace-neutral {}-block style would to me only feel as an improvement. Syntactic whitespace makes it harder to automatically reindent code, makes it easier to accidentally break the code structure and generally makes refactoring a pain. Furthermore I suspect the syntactic-whitespace to be the reason pythons lambda-statements are severely limited.
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?
Pedantry: By definition, you decimate your army by killing 10%. If you select 1% of your army and decimate that, then you only kill 0.1%. And it's really not like decimation at all--if someone doesn't fit into the project, their departing the project just improves cohesion. Decimation was intended to terrorize the troops.
In Repressive Burma, it's not just your connection that dies. slashdot.org/comments.pl?sid=314547&cid=20819199