July 31, 2007 — originally posted on artima.com
This is a sequal to last week's post. It's tempting to replace most Q/A pairs below with
Q. Will Python 3000 have feature X (which has not been proposed yet)?
A. No. The deadline for feature proposals (PEPs) was April 30, 2007.
but I figured it would be better to try to explain why various ideas (most of which aren't new) weren't proposed, or why they were rejected.
Q. Will implicit string concatenation be removed in Python 3000? (I.e., instead of ("a" "b") you'd have to write ("a" + "b").)
A. No. This was proposed in PEP 3126, but rejected.
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.
Q. Why doesn't str(c for c in X) return the string of concatenated c values?
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.