Q. Will the binary API for strings be standardized in Python 3000?
(Depending on a compile-time switch, Unicode strings use either a
2-byte wide or 4-byte wide representation.)

A. No, there are still compelling reasons to support 2 bytes in
some cases and 4 bytes in others. Usually this is dealt with by
compiling from source with the headers corresponding to the installed
Python binary. If that doesn't work for you, and you really care
about this, I recommend that you bring it up on the python-3000
mailing list, explaining your use case.

Q. Why isn't the GIL (Global Interpreter Lock) recursive?

A. Several reasons. Recursive locks are more expensive, and the
GIL is acquired and released a lot. Python's thread package doesn't
implement recursive locks in C (they are an add-on written in Python,
see RLock in threading.py). Given the different thread APIs on
different platforms it's important that the C code involved in threads
is minimal. But perhaps the most important reason is that the GIL
often gets released around I/O operations. Releasing only a single
level of a recursive lock would not be correct here; one would have to
release the underlying non-recursive lock and restore the recursion
level after re-acquiring. This is all rather involved. A
non-recursive lock is much easier to deal with.

Q. Will we be able to use statements in lambda in Python 3000?

A. No. The syntax (turning indentation back on inside an
expression) would both awkward to implement and hard to read for
humans. My recommendation is just to define a local (i.e., nested)
function -- this has the same semantics as lambda without the
syntactic restrictions. After all, this:

foo = lambda: whatever

is completely equivalent to this:

def foo(): return whatever

(except that the lambda doesn't remember its name).

Q. Will Python 3000 require tail call optimization?

A. No. The argument that this would be a "transparent"
optimization is incorrect -- it leads to a coding style that
essentially depends on tail call optimization, at which point the
transparency is lost. (Otherwise, why bother asking to require it?
:-) Also, tracebacks would become harder to read. Face reality --
Python is not a functional language. It works largely by side
effects on mutable objects, and there is no opportunity for program
transformation based on equivalent semantics.

Q. Will Python 3000 provide "real" private, protected and public?

A. No. Python will remain an "open kimono" language.

Q. Will Python 3000 support static typing?

A. Not as such. The language would turn into Java-without-braces.
However, you can use "argument annotations" (PEP 3107) and write
a decorator or metaclass to enforce argument types at run-time. I
suppose it would also be possible to write an extension to
pychecker or pylint that used annotations to check call
signatures.

A. Then, to be consistent, str(['a','b','c']) would have to
return 'abc'. I don't think you want that. Also, what would
str([1,2,3]) do? It's a grave problem if str() ever raises
an exception because that means the argument cannot be printed:
print calls str() on each of its arguments.

Talk Back!

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

RSS Feed

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

About the Blogger

Guido van Rossum is the creator of Python, one of the major
programming languages on and off the web. The Python community refers to him as the BDFL (Benevolent Dictator For Life), a title straight
from a Monty Python skit. He moved from the Netherlands to the USA in
1995, where he met his wife. Until July 2003 they lived in the
northern Virginia suburbs of Washington, DC with their son Orlijn, who
was born in 2001. They then moved to Silicon Valley where Guido now works for Google
(spending 50% of his time on Python!).