|[Home] [Credit Search] [Category Browser] [Staff Roll Call]||The LINUX.COM Article Archive|
|Originally Published: Friday, 1 September 2000||Author: Jeff Alami and Jason Tackaberry|
|Published to: develop_articles/Development Articles||Page: 1/1 - [Std View]|
An Interview with Guido van Rossum
Guido van Rossum is the creator of the Python programming language, and has worked on Python for ten years. He is the Director of PythonLabs, the leading resource for Python expertise and technologies.
Linux.com: What is CNRI's relationship to Python?
Guido van Rossum: CNRI funded Python development for five years. The money came mostly from NSF and DARPA research funds. Some of it came also from other sources: PSA (Python Software Activity) membership fees, Python Consortium membership fees, and specific funding by companies with an interest in Python.
I left CNRI in May, taking three other developers with me, to join a California startup, BeOpen.com. We are still living and working in the DC metro area. We left because it had become apparent that CNRI was vastly reducing the funding level for Python, moving most of us to other projects, and also because we felt that CNRI did not appreciate open source software development enough.
Since then, the relationships with CNRI have been strained. CNRI insisted to change the Python license in a way that caused lots of questions and worries from the community. I hope that eventually CNRI's control over future Python developments will be reduced to zero, but for now CNRI still has control over the python.org website and the new license encumbers all future versions of Python until I find the time for a complete rewrite from scratch.
Of course, I'm grateful for CNRI's support, and will always acknowledge its copyright on Python versions 1.3 through 1.6 -- with the understanding that many others have contributed as well, including CWI, my employer before I joined CNRI.
Linux.com: How did the Python project get involved with BeOpen.com?
Guido van Rossum: When we (the four CNRI developers who are now with BeOpen.com) felt that CNRI was no longer as Python-friendly as it used to be, we decided to shop around for a Python and open-source friendly company that was willing to hire us as a team. There were several interested companies; we chose BeOpen.com because it had the most pro-open-source attitude. Since then, BeOpen.com has done a lot for us and for Python -- e.g. without BeOpen.com, CNRI's Python license would have been much less open-source friendly.
Linux.com: Aside from Unicode support, what new features can developers expect to see in Python 1.6?
Guido van Rossum: We also have a new regular expression engine, developed by Fredrik Lundh (of PythonWorks fame). This was necessary to support regular expressions for Unicode strings. The new engine is fully compatible with the old "re" module, and much faster.
Also related to Unicode support, but useful in all contexts: string operations can now be expressed through string methods, e.g. s.strip() instead of string.strip(s).
Greg Ward's "distutils" package is included in 1.6: this will make installing, building and distributing third party packages much simpler.
The apply() function is redundant: instead of apply(f, args) -- which calls f with arguments taken from a tuple -- you can now say f(*args). The general form is f(val, ..., kw=val, ..., *argtuple, **kwdict).
IDLE, the Tkinter-based Python development environment, is much enhanced since the version that was included with Python 1.5.2.
There's support for memory-mapped files on Unix and Windows.
We spent a lot of time fixing bugs: for example, several cases of infinite recursion (e.g. comparing self-referential data structures) have been fixed.
Some incompatible changes: you can no longer say list.append(1,2,3) -- you must say list.append((1,2 3)). Ditto for socket.bind() and socket.connect() -- the (host, port) argument must be passed as an explicit tuple. The obsolete syntax was never documented, but accepted by accident.
There are some changes related to conversions beween numbers and strings; e.g. str() of a long int no longer appends 'L' (repr() still does!), repr() of a float gives 17 significant digits (enough to reconstruct the value exactly on all current hardware), and int() and long() now take an optional base argument, obsoleting the string functions atoi() and atol() (atof() was already obsolete).
A very subtle one: when a name that is known to be a local variable is undefined, the exception UnboundLocalError is raised instead of NameError. The new exception is a subclass of NameError, so code catching NameError will still work; but this gives much clearer diagnostic in cases like this:
x = 1
...100s of lines of code...
x = 2
There's lots more; see http://www.python.org/1.6/ for a more detailed list.
Linux.com: What's in store for Python 1.7. Will there be a version 2.0?
Guido van Rossum: To celebrate the move to BeOpen, the next version after 1.6 will be called 2.0. Some people have called this an unwarranted discontinuity in Python's versioning, but most folks agree with me that for better acceptance in the corporate world, a version number starting with 1 doesn't look very good.
We are already working on the beta cycle for Python 2.0; for a peek at what's new, please have a look at a document by Andrew Kuchling and Moshe Zadka, What's New in Python 2.0.
2.0 will have several syntax extensions over 1.6, e.g. augmented assignment, list comprehensions, and an extension to the print statement. It will also have lots of XML support (mostly integrating the good work done by the XML-sig) and a new garbage collection feature, which will collect cyclical garbage for the first time in Python's life.
Examples of the new syntax:
x = 1
x += 2 # same as x = x + 2
l = [1,2,3]
l += [4,5,6] # same as l.extend([4,5,6])
[x**2 for x in range(10)] # [0, 1, 4, 9, 16, 25, 36, 49, 64, 81]
[x for x in range(10) if x%3 != 0] # [1, 2, 4, 5, 7, 8]
extended print statement:
print >> sys.stderr, "hello world" # prints to sys.stderr
We're already collecting ideas for Python 2.1, now that we have declared a complete feature freeze for 2.0.
Linux.com: How do you see Python progressing in the future? What plans do you have for Python 3000? What core changes will be made to the language? Why do you feel these changes are necessary from current versions? What parts of the current versions do you feel are poorly designed?
Guido van Rossum: Very little is known about Python 3000. Not even what language will be used to implement it. Certainly not what changes will be made!
The key idea is that Python 3000 is our first (and probably last :-) ) opportunity to make incompatible changes to the language and its main implementation, and to fix bad design decisions that couldn't be fixed easily without being incompatible. At the same time I hope that starting from scratch with the implementation will allow us to get rid of some implementation warts that have been bugged us for a long time, such as the distinction between classes and built-in types, which prevents you from subclassing built-in types.
Other areas where I think a fresh start would help are integer division: 1/2 should really return 0.5, not 0, if we ever want to make Python a language for casual programming; and at the other end of the spectrum, metaclasses, which make even my own head explode.
At the same time, I've received a lot of feedback from people who are worried about the incompatibility of Python 3000. Will they have to learn a whole new language? Will they have to rewrite all their Python code? Should they even bother learning the current version of Python?
The answer to this is, Python 3000 is a long way away (probably 2 years before it's stable), so you should definitely not sit on your hands waiting for it. We'll provide backwards compatibility features, possibly translators (like the Perl folks are considering), possibly acceptance of old language features with warnings. We'll also provide *forward* compatibility features: Python 2.1 and later may warn you when you are using a feature that will be deprecated in Python 3000.
Linux.com: What do you consider to be the most interesting area of programming language theory? Will any of these areas be influencing the design of Python 3000?
Guido van Rossum: I'm a practitioner, not a theoretician... Things that interest me most are user issues: usability of the language or of particular features, usability of environments. User testing. How do various groups of users actually use Python?
This will definitely influence Python 3000 -- hard-to-use features will be replaced with easier ones.
Linux.com: If you had to convince a room full of Perl developers to consider Python for their next large project, what would you say?
Guido van Rossum: "Have you ever had to maintain someone else's Perl code?"
Linux.com: What is your advice to the newbie coder willing to learn Python as a first language?
Guido van Rossum: Try some of the introductions for non-programmers from http://www.python.org/doc/Intros.html.
Linux.com: What's your favourite Monty Python sketch?
Guido van Rossum: Lots, e.g. dead parrot, argument. I like the Meaning of Life a lot, e.g. "we've come for your liver."