Summary
Guido van Rossum published a reply to my article "Python 3K or Python 2.9."

Guido's response is here.

First, I bring up these issues because I want my favorite language to be better, not because I am criticizing Guido or his process. I've worked with a number of languages in some depth and the job done by Guido and the top-level committers is better than any I've seen -- and I've personally spent time with these folks. What's amazing about Python is that it is not a one-person operation; there's a real team that is making decisions, and Guido pushes down those decisions so that he doesn't make them personally if he doesn't have to (which, I think, would be too exhausting, for one thing).

Guido's continuing drumbeat of "contribute, contribute" is absolutely essential. And although contributing PEPs and code is contribution in the most real sense -- which I hope to do myself someday -- I think that creating conversations is also an important contribution.

Some of the requests I made are certainly unreasonable or impractical, but I think we need to be careful about issues that become superstition: "we talked about that once and it didn't work so that topic is done," "maybe that would be better but it's too much trouble" or (my favorite) "that couldn't possibly be efficient enough to be justified."

And the other issues I can live with, but when it comes to concurrency, the world is changing and we can't leave our heads in the sand about it, especially considering that multiple CPUs could obliterate the "Python is slow" argument.

In particular (this is to everyone, not just Guido), be careful when assuming that threads are the right solution. We came to threads through a series of steps, like the temperature being turned up on a frog in a pan of water. People assume that you "must have threads to do concurrency properly." But threads are fraught with problems and notoriously difficult -- some experts even say impossible -- to get right (hey, the GIL might be your friend a lot more than you know). Yes, with processes you don't get everything you get with threads, but you can use multicores and multiple machines right now and write robust code because the OS is protecting you by not allowing you to share memory. That's a good thing! As far as overhead goes, I hope that we may start to see cleverer solutions -- in the same vein as ctypes solves its problem optimally -- as the issues become clearer. But for now, pretend that any expensive problem can be distributed to as many CPUs as you want, because from that perspective Python begins to look like the most effective language on all counts: if you can write it quickly and you can use distribution to make it run fast enough, then Python becomes the cheapest solution.

Talk Back!

Have an opinion? Readers have already posted 21 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Bruce Eckel adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Bruce Eckel (www.BruceEckel.com) provides development assistance in Python with user interfaces in Flex. He is the author of Thinking in Java (Prentice-Hall, 1998, 2nd Edition, 2000, 3rd Edition, 2003, 4th Edition, 2005), the Hands-On Java Seminar CD ROM (available on the Web site), Thinking in C++ (PH 1995; 2nd edition 2000, Volume 2 with Chuck Allison, 2003), C++ Inside & Out (Osborne/McGraw-Hill 1993), among others. He's given hundreds of presentations throughout the world, published over 150 articles in numerous magazines, was a founding member of the ANSI/ISO C++ committee and speaks regularly at conferences.