6 ms·

What’s New In Python 3.3

178 points by ch0wn 15y ago

Flimm 15y ago
The os module now has a new function: pipe2. Is there a reason why they didn't give it a better name, like pipe_with_flags?
- thristian 15y ago
  I'm guessing it's named after the underlying POSIX function pipe2().
- wulczer 15y ago
  The underlying syscall and libc function are called pipe2.
tocomment 15y ago
I think they really need a killer feature in the 3.x branch to drive adoption. Any ideas?
- dmbaggett 15y ago
  Source-code compatibility with Python 2.X?
  - mattchaput 15y ago
    That would have been a nice driver, too bad they didn't do it.
- deleted 15y ago
  [deleted]
- e1ven 15y ago
  The non-fucked Unicode support is a good driver. Having ported programs that accept multiple types of strings from Py2 to Py3, Py3 is DRAMATICALLY easier to work with here. The biggest downside is that in order to upgrade from Py2->3, I needed to patch half a dozen different libs.
- jemeshsu 15y ago
  It's DJango.
- sho_hn 15y ago
  I don't think they do, myself. Adoption will and is happening gradually. More and more libs are being ported, and new Python coders often learn "Python 3 and how 2 differs" (rather than the other way around), e.g. thanks to Lutz' book. Eventually there just won't be any reasons left to use 2, and the usual reasons to use the latest version kick in - incremental improvements and continued maintenance. The migration was always expected to be a long-term thing, and so far has been pretty pain-free imho. But then I haven't written any code that doesn't run in 3.x since 2010, finding that 3 increasingly meets my deps and is more enjoyable and productive to code in, and when I do need to support 2 that the common subset of 2.7 and 3 is large enough to do many things.
  - tocomment 15y ago
    What makes 3 more enjoyable/productive?
    - sho_hn 15y ago
      Unicode strings by default is a big one for me, but the little things sum up too: The removal of x*() functions in favor of making things that should return iterators just do so, removing old-style classes, various little consistency gains in standard object interfaces/protocols, lots of standard lib organization cleanups. I simply find things in Python 3 are the way I expect or want them to be more often than in 2, reducing the number of gotchas I need to keep track of. Heck, even print() is a solid improvement in my book (keyword args, hooray!) and I appreciate not needing the __future__ import for it. The list gets longer of course if you fairly add all the things eventually backported to 2.7, e.g. set literals and comprehensions. So, does 2.x work? Sure. Is 3 better? Yup. If I get to pick one, I pick 3.
- rmc 15y ago
  For me, unicode everywhere is cool. (Yes a PITA to work with, but it should be a PITA if you only assume ASCII)
  - abecedarius 15y ago
    Going in, I expected it to not be a PITA to assume UTF-8 like in Plan 9. (I guess I was naive.)
overshard 15y ago
I find a lot of 3.x new features to be improvements from 2.x but everyone still uses 2.x. I fear that we will be on Python 4.x by the time 3.x adoption starts to actually happen en masse. From what me and my coworkers have discussed we are basically all waiting on Django to get Python 3.x adoption. I've tried submitting multiple patches for this and helping Django as much as possible but they don't seem to want outside help. Come on Django, come on, a lot of us are waiting for you.
- ubernostrum 15y ago
  As I've said pretty consistently: getting Django onto Python 3 is not a technical code-porting issue. In fact, experimental Django-on-Python-3 branches exist and, so far as I'm aware, run pretty well. The problem is and continues to be the social and community issue of gracefully deprecating our way out of Python 2.x, which we're basically doing at a rate of one Python version per Django release. All the patches in the world can't really make this process go faster :)
  - overshard 15y ago
    And this is understandable, but as long as the branches for 3.x Django are "experimental" or created by a third party I'm not willing to put them into a stable production environment. Maybe Django just needs to come up with a 3.x branch to develop as stable along side the 2.x branch till 2.x starts to die out?
- 16s 15y ago
  Lot's of huge working code bases (in-house apps) are using Python 2. It works, it's been tested, it's in production daily. What's the compelling business reason to change? And 2 to 3 is a substantial change. If we're going to do this and pay the cost to do so, we may as well investigate other options (outside of Python) while we're at it.
  - overshard 15y ago
    Yes you should investigate other options outside of Python, on a regular basis I keep up to date on other frameworks/languages and on a regular basis I decide that Python is still the right choice for me. If you aren't doing this on a regular basis (at least once a year seriously considering where your framework/language of choice is on the market) then I think there is a serious problem. The CS world changes so fast that you always need to consider if what you are doing is simply outdated and you should pay the cost to stay current. However if that cost still isn't worth it and everything is working on your outdated, legacy hardware and software and you can still keep up with the market than you're good. I simply like to keep myself up with the market/community, when I release new software I try and make sure I'm not releasing something on a platform that will be dead in a month.
agentultra 15y ago
I'm pretty excited for the small changes like zero-copy and the 'x' file open flag. Oh, and the new OSError exception hierarchy. Some of these things could be back-ported to Python 2.7 as libraries but I'd much rather see a bigger push to move onto Python 3 instead. I look forward to even more Python 3 awesomeness in the future. Each release is a compelling reason to start porting.
- riobard 15y ago
  I wish they could add os.splice() and os.tee() on Linux, too.
amix 15y ago
I am not really that excited about any of these features that's in 3.3 (or even in Python 3). The biggest problem I have is that Python 2 works "good enough" and upgrading to Python 3 does not have many benefits, other than lots of work and slower performance. I guess a lot of people feel the same way, hence the slow or non existing adoption of Python 3. I guess Python 3 might end up as Perl 6 if this continues since we keep investing time on Python 2.x libraries and features. What we need is a reason to upgrade and the killer feature of Python 3 could be performance. I would upgrade to Python 3 in a instance if it offered a lot better performance than Python 2. How do we achieve better performance? Adopt PyPy as the reference implementation for Python 3 and all future references. Making PyPy a centerpiece of Python 3+ would probably mean it would mature faster. PyPy is focused right now on Python 2.X, but I would rather see it focus on the future of Python and being a killer feature of Python 3+.
- agentultra 15y ago
  I find your claims are unsubstantiated and would require some evidence to be convincing. For example, the performance of Python 3.0 was slow on I/O operations. The reason was because the I/O modules were written in pure-python in order to get the ball rolling. This wasn't a bug. However, the code was eventually ported to C in 3.1 and unsurprisingly the performance improved: http://www.gtsystem.eu/blog/2009/08/improved-performance-of-python-31/ http://www.gtsystem.eu/blog/2009/08/improved-performance-of-... And that's an old post from 2009! The performance is much better today. Features they're releasing in this new version include zero-copy in os.copyfile() which is totally sweet. No user-space buffers involved in transferring bytes from a file to a socket. This should speed up such operations well past what any version of python 2.x is capable of. There isn't a feature in Python 3 that is not substantially better than 2.x -- they're fixing all the fiddly bits and producing a much better language. There is no feature they can create which will open the dam to a flood of porting projects. The reason is that the problem is a social one. An honest-to-goodness effort to port the large libraries requires a plan to support the existing 2.x versions alongside the 3.x versions so that the people who are still running applications built on the old versions will still work. This requires extra effort that is difficult to acquire in open source projects let alone commercial ones. Even if the Python 3 devs added a feature that materialized ponies out of thin air there would still be projects running the 2.x code.
kamaal 15y ago
Should we develop on Python 3.x series or 2.x series? Libraries aren't really ready for 3.x series and developing on 2.x series is not making any sense as if 2.x ultimately goes away then migration effort on that is not worth. At the same time 3.x ecosystem is not ready either.
- jacobian 15y ago
  The general advice I give is: "Python 3 if you can, Python 2 if you must." That is, if you can use Python 3, you should: it's the future of the language, and it feels it. I find Python 3 significantly more pleasant than Python 2; nearly all the bits that annoy me about Python are fixed in 3. Python 3 is cleaner, the standard library is de-crufted and easier to navigate, and (most important to me) handling unicode doesn't suck. However, as others in this thread note, significant parts of the Python ecosystem haven't finished porting yet (Django, Twisted, yada yada yada). If you rely on one of those things, then stick with Python 2. If that code lives fo a long time you will have to face a porting effort later on, but that's improving somewhat as the community discovers new techniques and creates new tools.
- deleted 15y ago
  [deleted]
- bobbyi 15y ago
  Most significant libraries and tools work with 3.x by this point. SQLAlchemy, numpy, scipy, cherrypy, WebOb, pymongo (as pymongo3), virtualenv, pip, pygments, jinja2, tox, nose, ... It's too bad that django, zope and werkzeug (flask) aren't there yet. I understand that a lot of people on this site use django and so these discussions are always dominated by people complaining that they can't use Python 3 because their dependencies (django) aren't available. But the Python community is much bigger than django and today most of the rest of the ecosystem is ready and working fine. The parts that aren't, are getting there rapidly.
- irahul 15y ago
  You can write forward compatible 2.x. Here is a small guide to pitfalls and writing forward compatible code: http://lucumr.pocoo.org/2011/1/22/forwards-compatible-python/ http://lucumr.pocoo.org/2011/1/22/forwards-compatible-python... Note that he advises leaving print statement be; it's more familiar in 2.x land, editors often are confused with print function syntax highlighting, and it's easily handled by 2to3.
ramanujan 15y ago
Unfortunately, Python 3 is the new Perl 6. It offers reduced performance[1], changes some of the hardest-to-debug parts of the language (like Unicode), and capriciously introduces backwards incompatibilities. For no obvious gain! As just one example, could Guido not have made the print statement a function through the simple mechanism of: from __future__ import printfn Then new code could use printfn and old code could use print, and all would be well. But instead, literally billions of dollars will be wasted changing every single print keyword statement to a print function invocation. Sure, you can use 2to3. But the tool is that worst of all worlds, a compiler that doesn't really work 100% and actually reduces the performance of your code in the compilation process. For those who do not want to waste their time on this port, Python 3 is going to accelerate the move towards full stack JS just like Perl 6 accelerated the move towards Python/Ruby. This JS stack will be MongoDB + node + Backbone/coffeescript or some similar permutation. After all, if you are going to literally have to recompile your language with 2to3 and deal with all the edge cases, why not go whole hog with something like emscripten[2] or a souped-up pyjamas[3] to convert your legacy Python 2 code to JS? Then people just need to start porting C/C++ numerical libraries over to V8 through something like v8-juice[4] and we will have all the missing pieces. [1] http://docs.python.org/release/3.0.1/whatsnew/3.0.html#performance http://docs.python.org/release/3.0.1/whatsnew/3.0.html#perfo... [2] https://github.com/kripken/emscripten/wiki https://github.com/kripken/emscripten/wiki [3] http://pyjs.org/ http://pyjs.org/ [4] http://code.google.com/p/v8-juice/ http://code.google.com/p/v8-juice/
- briancurtin 15y ago
  > http://docs.python.org/release/3.0.1/whatsnew/3.0.html#performance http://docs.python.org/release/3.0.1/whatsnew/3.0.html#perfo... The thread is about 3.3, so you link to a 3.0.1 release note? That is three years old. > literally billions of dollars will be wasted changing every single print keyword statement to a print function I'd love to see the math on this, especially because I did it in a matter of minutes across all of my code.
  - ramanujan 15y ago
    > 3 years old I'm pretty sure they'd have announced it if Python 3 ever got faster than Python 2. But this is not mentioned in the 3.1, 3.2, or 3.3 notes on performance: http://docs.python.org/dev/whatsnew/3.1.html#optimizations http://docs.python.org/dev/whatsnew/3.2.html#optimizations http://docs.python.org/dev/whatsnew/3.3.html#optimizations > see the math That one is easy. The Python 3 conversion is a serious project for core devs at Django and Numpy. Check out their mailing lists about what this takes/took. http://blog.jarrodmillman.com/2009/01/when-will-numpy-and-scipy-migrate-to.html http://blog.jarrodmillman.com/2009/01/when-will-numpy-and-sc... While the above procedure of using the 2to3 tool works relatively for pure Python code, there is no automatic conversion tool for extension code. NumPy is mostly written in C and makes extensive use of the Python C-API. So converting NumPy will require much more than running the 2to3 tool. https://docs.djangoproject.com/en/dev/faq/install/#can-i-use-django-with-python-3 https://docs.djangoproject.com/en/dev/faq/install/#can-i-use... ... it will be a while before most Python software catches up and is able to run on Python 3.0. For larger Python- based software like Django, the transition is expected to take at least a year or two (since it involves dropping support for older Python releases and so must be done gradually). A "year or two" of the core Django team's time is easily several million bucks. Multiply by the Python codebases of every company on this list [1], and everyone on github, and every egg out there, and we are talking billions for the conversion. [1] http://wiki.python.org/moin/OrganizationsUsingPython http://wiki.python.org/moin/OrganizationsUsingPython

178 points by ch0wn 15y ago

Flimm 15y ago

The os module now has a new function: pipe2. Is there a reason why they didn't give it a better name, like pipe_with_flags?

thristian 15y ago
I'm guessing it's named after the underlying POSIX function pipe2().
wulczer 15y ago
The underlying syscall and libc function are called pipe2.

tocomment 15y ago

I think they really need a killer feature in the 3.x branch to drive adoption. Any ideas?

dmbaggett 15y ago
Source-code compatibility with Python 2.X?
- mattchaput 15y ago
  That would have been a nice driver, too bad they didn't do it.
deleted 15y ago
[deleted]
e1ven 15y ago
The non-fucked Unicode support is a good driver. Having ported programs that accept multiple types of strings from Py2 to Py3, Py3 is DRAMATICALLY easier to work with here. The biggest downside is that in order to upgrade from Py2->3, I needed to patch half a dozen different libs.
jemeshsu 15y ago
It's DJango.
sho_hn 15y ago
I don't think they do, myself. Adoption will and is happening gradually. More and more libs are being ported, and new Python coders often learn "Python 3 and how 2 differs" (rather than the other way around), e.g. thanks to Lutz' book. Eventually there just won't be any reasons left to use 2, and the usual reasons to use the latest version kick in - incremental improvements and continued maintenance. The migration was always expected to be a long-term thing, and so far has been pretty pain-free imho. But then I haven't written any code that doesn't run in 3.x since 2010, finding that 3 increasingly meets my deps and is more enjoyable and productive to code in, and when I do need to support 2 that the common subset of 2.7 and 3 is large enough to do many things.
- tocomment 15y ago
  What makes 3 more enjoyable/productive?
  - sho_hn 15y ago
    Unicode strings by default is a big one for me, but the little things sum up too: The removal of x*() functions in favor of making things that should return iterators just do so, removing old-style classes, various little consistency gains in standard object interfaces/protocols, lots of standard lib organization cleanups. I simply find things in Python 3 are the way I expect or want them to be more often than in 2, reducing the number of gotchas I need to keep track of. Heck, even print() is a solid improvement in my book (keyword args, hooray!) and I appreciate not needing the __future__ import for it. The list gets longer of course if you fairly add all the things eventually backported to 2.7, e.g. set literals and comprehensions. So, does 2.x work? Sure. Is 3 better? Yup. If I get to pick one, I pick 3.
rmc 15y ago
For me, unicode everywhere is cool. (Yes a PITA to work with, but it should be a PITA if you only assume ASCII)
- abecedarius 15y ago
  Going in, I expected it to not be a PITA to assume UTF-8 like in Plan 9. (I guess I was naive.)

overshard 15y ago

I find a lot of 3.x new features to be improvements from 2.x but everyone still uses 2.x. I fear that we will be on Python 4.x by the time 3.x adoption starts to actually happen en masse. From what me and my coworkers have discussed we are basically all waiting on Django to get Python 3.x adoption. I've tried submitting multiple patches for this and helping Django as much as possible but they don't seem to want outside help. Come on Django, come on, a lot of us are waiting for you.

ubernostrum 15y ago
As I've said pretty consistently: getting Django onto Python 3 is not a technical code-porting issue. In fact, experimental Django-on-Python-3 branches exist and, so far as I'm aware, run pretty well. The problem is and continues to be the social and community issue of gracefully deprecating our way out of Python 2.x, which we're basically doing at a rate of one Python version per Django release. All the patches in the world can't really make this process go faster :)
- overshard 15y ago
  And this is understandable, but as long as the branches for 3.x Django are "experimental" or created by a third party I'm not willing to put them into a stable production environment. Maybe Django just needs to come up with a 3.x branch to develop as stable along side the 2.x branch till 2.x starts to die out?
16s 15y ago
Lot's of huge working code bases (in-house apps) are using Python 2. It works, it's been tested, it's in production daily. What's the compelling business reason to change? And 2 to 3 is a substantial change. If we're going to do this and pay the cost to do so, we may as well investigate other options (outside of Python) while we're at it.
- overshard 15y ago
  Yes you should investigate other options outside of Python, on a regular basis I keep up to date on other frameworks/languages and on a regular basis I decide that Python is still the right choice for me. If you aren't doing this on a regular basis (at least once a year seriously considering where your framework/language of choice is on the market) then I think there is a serious problem. The CS world changes so fast that you always need to consider if what you are doing is simply outdated and you should pay the cost to stay current. However if that cost still isn't worth it and everything is working on your outdated, legacy hardware and software and you can still keep up with the market than you're good. I simply like to keep myself up with the market/community, when I release new software I try and make sure I'm not releasing something on a platform that will be dead in a month.

agentultra 15y ago

I'm pretty excited for the small changes like zero-copy and the 'x' file open flag. Oh, and the new OSError exception hierarchy. Some of these things could be back-ported to Python 2.7 as libraries but I'd much rather see a bigger push to move onto Python 3 instead. I look forward to even more Python 3 awesomeness in the future. Each release is a compelling reason to start porting.

riobard 15y ago
I wish they could add os.splice() and os.tee() on Linux, too.

amix 15y ago

I am not really that excited about any of these features that's in 3.3 (or even in Python 3). The biggest problem I have is that Python 2 works "good enough" and upgrading to Python 3 does not have many benefits, other than lots of work and slower performance. I guess a lot of people feel the same way, hence the slow or non existing adoption of Python 3. I guess Python 3 might end up as Perl 6 if this continues since we keep investing time on Python 2.x libraries and features. What we need is a reason to upgrade and the killer feature of Python 3 could be performance. I would upgrade to Python 3 in a instance if it offered a lot better performance than Python 2. How do we achieve better performance? Adopt PyPy as the reference implementation for Python 3 and all future references. Making PyPy a centerpiece of Python 3+ would probably mean it would mature faster. PyPy is focused right now on Python 2.X, but I would rather see it focus on the future of Python and being a killer feature of Python 3+.

agentultra 15y ago
I find your claims are unsubstantiated and would require some evidence to be convincing. For example, the performance of Python 3.0 was slow on I/O operations. The reason was because the I/O modules were written in pure-python in order to get the ball rolling. This wasn't a bug. However, the code was eventually ported to C in 3.1 and unsurprisingly the performance improved: http://www.gtsystem.eu/blog/2009/08/improved-performance-of-python-31/ http://www.gtsystem.eu/blog/2009/08/improved-performance-of-... And that's an old post from 2009! The performance is much better today. Features they're releasing in this new version include zero-copy in os.copyfile() which is totally sweet. No user-space buffers involved in transferring bytes from a file to a socket. This should speed up such operations well past what any version of python 2.x is capable of. There isn't a feature in Python 3 that is not substantially better than 2.x -- they're fixing all the fiddly bits and producing a much better language. There is no feature they can create which will open the dam to a flood of porting projects. The reason is that the problem is a social one. An honest-to-goodness effort to port the large libraries requires a plan to support the existing 2.x versions alongside the 3.x versions so that the people who are still running applications built on the old versions will still work. This requires extra effort that is difficult to acquire in open source projects let alone commercial ones. Even if the Python 3 devs added a feature that materialized ponies out of thin air there would still be projects running the 2.x code.

kamaal 15y ago

Should we develop on Python 3.x series or 2.x series? Libraries aren't really ready for 3.x series and developing on 2.x series is not making any sense as if 2.x ultimately goes away then migration effort on that is not worth. At the same time 3.x ecosystem is not ready either.

jacobian 15y ago
The general advice I give is: "Python 3 if you can, Python 2 if you must." That is, if you can use Python 3, you should: it's the future of the language, and it feels it. I find Python 3 significantly more pleasant than Python 2; nearly all the bits that annoy me about Python are fixed in 3. Python 3 is cleaner, the standard library is de-crufted and easier to navigate, and (most important to me) handling unicode doesn't suck. However, as others in this thread note, significant parts of the Python ecosystem haven't finished porting yet (Django, Twisted, yada yada yada). If you rely on one of those things, then stick with Python 2. If that code lives fo a long time you will have to face a porting effort later on, but that's improving somewhat as the community discovers new techniques and creates new tools.
deleted 15y ago
[deleted]
bobbyi 15y ago
Most significant libraries and tools work with 3.x by this point. SQLAlchemy, numpy, scipy, cherrypy, WebOb, pymongo (as pymongo3), virtualenv, pip, pygments, jinja2, tox, nose, ... It's too bad that django, zope and werkzeug (flask) aren't there yet. I understand that a lot of people on this site use django and so these discussions are always dominated by people complaining that they can't use Python 3 because their dependencies (django) aren't available. But the Python community is much bigger than django and today most of the rest of the ecosystem is ready and working fine. The parts that aren't, are getting there rapidly.
irahul 15y ago
You can write forward compatible 2.x. Here is a small guide to pitfalls and writing forward compatible code: http://lucumr.pocoo.org/2011/1/22/forwards-compatible-python/ http://lucumr.pocoo.org/2011/1/22/forwards-compatible-python... Note that he advises leaving print statement be; it's more familiar in 2.x land, editors often are confused with print function syntax highlighting, and it's easily handled by 2to3.

ramanujan 15y ago

Unfortunately, Python 3 is the new Perl 6. It offers reduced performance[1], changes some of the hardest-to-debug parts of the language (like Unicode), and capriciously introduces backwards incompatibilities. For no obvious gain! As just one example, could Guido not have made the print statement a function through the simple mechanism of: from __future__ import printfn Then new code could use printfn and old code could use print, and all would be well. But instead, literally billions of dollars will be wasted changing every single print keyword statement to a print function invocation. Sure, you can use 2to3. But the tool is that worst of all worlds, a compiler that doesn't really work 100% and actually reduces the performance of your code in the compilation process. For those who do not want to waste their time on this port, Python 3 is going to accelerate the move towards full stack JS just like Perl 6 accelerated the move towards Python/Ruby. This JS stack will be MongoDB + node + Backbone/coffeescript or some similar permutation. After all, if you are going to literally have to recompile your language with 2to3 and deal with all the edge cases, why not go whole hog with something like emscripten[2] or a souped-up pyjamas[3] to convert your legacy Python 2 code to JS? Then people just need to start porting C/C++ numerical libraries over to V8 through something like v8-juice[4] and we will have all the missing pieces. [1] http://docs.python.org/release/3.0.1/whatsnew/3.0.html#performance http://docs.python.org/release/3.0.1/whatsnew/3.0.html#perfo... [2] https://github.com/kripken/emscripten/wiki https://github.com/kripken/emscripten/wiki [3] http://pyjs.org/ http://pyjs.org/ [4] http://code.google.com/p/v8-juice/ http://code.google.com/p/v8-juice/

briancurtin 15y ago
> http://docs.python.org/release/3.0.1/whatsnew/3.0.html#performance http://docs.python.org/release/3.0.1/whatsnew/3.0.html#perfo... The thread is about 3.3, so you link to a 3.0.1 release note? That is three years old. > literally billions of dollars will be wasted changing every single print keyword statement to a print function I'd love to see the math on this, especially because I did it in a matter of minutes across all of my code.
- ramanujan 15y ago
  > 3 years old I'm pretty sure they'd have announced it if Python 3 ever got faster than Python 2. But this is not mentioned in the 3.1, 3.2, or 3.3 notes on performance: http://docs.python.org/dev/whatsnew/3.1.html#optimizations http://docs.python.org/dev/whatsnew/3.2.html#optimizations http://docs.python.org/dev/whatsnew/3.3.html#optimizations > see the math That one is easy. The Python 3 conversion is a serious project for core devs at Django and Numpy. Check out their mailing lists about what this takes/took. http://blog.jarrodmillman.com/2009/01/when-will-numpy-and-scipy-migrate-to.html http://blog.jarrodmillman.com/2009/01/when-will-numpy-and-sc... While the above procedure of using the 2to3 tool works relatively for pure Python code, there is no automatic conversion tool for extension code. NumPy is mostly written in C and makes extensive use of the Python C-API. So converting NumPy will require much more than running the 2to3 tool. https://docs.djangoproject.com/en/dev/faq/install/#can-i-use-django-with-python-3 https://docs.djangoproject.com/en/dev/faq/install/#can-i-use... ... it will be a while before most Python software catches up and is able to run on Python 3.0. For larger Python- based software like Django, the transition is expected to take at least a year or two (since it involves dropping support for older Python releases and so must be done gradually). A "year or two" of the core Django team's time is easily several million bucks. Multiply by the Python codebases of every company on this list [1], and everyone on github, and every egg out there, and we are talking billions for the conversion. [1] http://wiki.python.org/moin/OrganizationsUsingPython http://wiki.python.org/moin/OrganizationsUsingPython