Q. I want to learn Python. Should I learn Python 2.6 or Python 3.0?

A. Definitely learn Python 2.x (the latest version out is 2.5). I expect it'll be two years before you'll need to learn Python 3.0, and the differences aren't that great from a beginner's perspective: most of what you'll learn about 2.x will still hold about 3.0.

Q. If you're killing reduce(), why are you keeping map() and filter()?

A. I'm not killing reduce() because I hate functional programming; I'm killing it because almost all code using reduce() is less readable than the same thing written out using a for loop and an accumulator variable. On the other hand, map() and filter() are often useful and when used with a pre-existing function (e.g. a built-in) they are clearer than a list comprehension or generator expression. (Don't use these with a lambda though; then a list comprehension is clearer and faster.)

Q. Multi-core processors will be standard even on laptops in the near future. Is Python 3.0 going to get rid of the GIL (Global Interpreter Lock) in order to be able to benefit from this feature?

A. No. We're not changing the CPython implementation much. Getting rid of the GIL would be a massive rewrite of the interpreter because all the internal data structures (and the reference counting operations) would have to be made thread-safe. This was tried once before (in the late '90s by Greg Stein) and the resulting interpreter ran twice as slow. If you have multiple CPUs and you want to use them all, fork off as many processes as you have CPUs. (You write your web application to be easily scalable, don't you? So if you can run several copies on different boxes it should be trivial to run several copies on the same box as well.) If you really want "true" multi-threading for Python, use Jython or IronPython; the JVM and the CLR do support multi-CPU threads. Of course, be prepared for deadlocks, live-locks, race conditions, and all the other nuisances that come with multi-threaded code.

Q. I prefer to use the same source code for 2.x and 3.0; I really don't want to have to use the 2to3 source conversion tool. Why can't you make that work?

A. Suit yourself. The intersection of 2.6 and 3.0 is large, but there are several things you can't do: you can't use Unicode literals (2.6 only), nor bytes literals (3.0 only). The only print syntax that works the same in both versions is print(x). When you catch exceptions you can't inspect their values, because the 2.6 syntax uses , while 3.0 uses as. You can't use .iterkeys(), but .keys() works differently in 2.6 and 3.0. You can't use xrange(), but range() works differently. You can't use metaclasses, as the syntax for specifying a metaclass is completely changed in 3.0. And so on. Restricting yourself to the intersection of the two versions is very painful and limited. We're not introducing backwards compatibility syntax in 3.0, because that would defeat the purpose (we've had backwards compatibility forever in 2.x, and the whole point of 3.0 is to clean up the mess).

P.S. For another batch of Q/A pairs, see the sequel post.

...
    map(def (x):
        for i in x:
            do some stuff...
        return z
    , some_list)
...

>>> str(i for i in "string" if i not in "aeiou")
'strng'

>>> mycond = lambda i: True
>>> it = [1, 2]
>>> type(it)(i for i in it if mycond(i))
[1, 2]
>>> it = (1, 2)
>>> type(it)(i for i in it if mycond(i))
(1, 2)
>>> it = set([1,2])
>>> type(it)(i for i in it if mycond(i))
set([1, 2])
>>> it = "abc"
>>> type(it)(i for i in it if mycond(i))
'<generator object at 0x789e0>'

> def compose(funs):
>     return lambda x: reduce(lambda z,f: f(z),
>                             list(reversed(funs)), x)

>>> def c(fs):
...   def F(x):
...     for f in reversed(fs): x = f(x)
...     return x
...   return F
...