By the way, do you think migrating to Python 3 would make sense for now or are there any reasons to hold on this process?

Personally I don't see really "next big things" in Python 3...

Did you looked on docs.python.org ?
I really like to see _decimal and signature objects

I personally dislike Python 3 a bit because of it's handling of bytes/strings issue. Although Go has behaviour vaguely similar to Py3 and I had no problems with it, in this case Go is more restrictive (it handles only UTF-8 and nothing else) and a bit more explicit (static typing and all that stuff).

I will try to migrate some code only after 3.3 stable comes.

Python 3.3 is first version worth to migrate to. But no need to wait for stable since there is a lot to do on our side.

That's interesting, personally I don't see a big win even from migrating to Python 3.3, though I think PyPy could make it much more sustainable. Thank you!

Tim, 3.3 rc1 have to be published this weekend, so you can start to try just now. Release date is scheduled to 22 sept.

Andrey, do you think Python as language is perfect and finished and you don't want any improvement?
Personally I like changes coming with every Python release.

PyPy is great project and interesting experiment (which now compatible with python 2.7 only btw).

Who uses PyPy in production? Do you know that man?

Andrew, no, I don't think Python is perfect and finished and I really am not satisfied about changes in Python — these are not that radical improvements I would like to see, examples:

- introduction of coroutines instead of abusing generators (remember "yield from" is being accepted now?)
- replaceable threading (think of using coroutines instead of OS-level threads)
- replaceable socket/signal/time APIs in stdlib (think of using epoll/kqueue under the hood)
- the absence of "compile-time" metaprogramming with mutable grammar (think of how MetaLua works)

Well, instead of these we have a bunch of "so-so" improvements and backward incompatibility — not nice...

Replaceable thread/socket/signal etc looks like monkeypatch in standard library itself for now.
Jim Fulton promised to make PEP for event loop, let's look on state after that.

About adding new grammars to language: python-dev discussed it periodically. The main objection for last time IIRC was over-complicating of debugging.

Like monkey-patching but w/o any monkeys :-). Ok looking forward to Jim's PEP.

Speaking of mutable grammar — I think macros system made right would be a great improvement over decorator abuse, hairy metaprogramming techniques with metaclasses (think of Django ORM).

I don't think python need macroses — it is already dynamic and flexible enough.
The last proposal was to specify maker for function which will generate AST from function body. Crazy technique!

> specify maker for function which will generate AST from function body

That's a form of macros.

Well, it can be called as syntactic macros.
I see related activity in python-dev.
Maybe sometimes it will be included in CPython in some form.
It can be very interesting, but a lot of work should be done before.
Keep in mind debugging, profiling and support for PyPy, Jython, IronPython etc. Good news: all of these has the same AST as CPython, at least developers confirmed passing tests for ast module and their _ast implementations follow CPython as close as possible.

Looks like GvR is skeptical for adding external grammars to .py files but he open for future movements.

BTW, I recall traceback game in jinja2 and importlib to get rid of noise in stack trace for exceptions.
Proposal for extra syntax should to care this also.