What's going on with python 3k ?

Question

Since I'm not strictly python developer please don't flame me just for the question.

I'm wondering about Python 3k, that from my point of view, might be some kind of misconception. Or quite in-relevant step forward (I'm taking into account the 2.6 and 3k releases, which was almost one after another). Before the flame will start, I'll explain my position at this topic and I'd assume couple facts from my work environment.

I work in a cutting edge market data solutions company, we use mainly functional languages to high throughput data analysis. But we also use python as a second technology for smaller tasks, scripts, process management & monitoring.

Some of my colleagues write more serious production applications based on python technologies, but:

• ALL of our customers use python 2.6,
• because of above we have quite strong 2.6 toolset and internal/external support,
• We still plan to develop 2.6 apps.

Every small tool development is also based on 2.6 platform.

Additional what I observe:

• at this point any new linux distribution (in our infrastructure) has python 2.6 on the board,
• most third party modules are developed for 2.6 version,
• great part of resources in the network is also dedicated for 2.6

(I know that You can port most of this to 3.1.x, but it's too big overhead here.)

I know that Py 3k is still growing but, there is already python 3.1.1, but no one "cares" (in my environment). I've a strong feeling that Python 3k overheads are stopping it for moving this great technology into new dimension.

Answer 1

What exactly is the question here? You observe that there's a newer version of the platform you currently use. You have good reason for staying with the version you have. This pattern is common across very many development organisations, you simply cannot chase every new version of the stuff yiou use. Nor can you stay where you are for ever, eventually you will need to migrate.

There are forces that may drive you to migrate, for example

• The new version has some very major new feature you would really benefit from (eg. annotations in Java 5)
• Support for a current platform (or dependent library) is being withdrawn

Meanwhile, you could attempt to future-proof your code so that migrating is easier. Are you familiar with the level of change required to move up?

Answer 2

Py3k is a good and necessary step in the evolution of the Python language. I like it much better than 2.x, and code in it almost exclusively. I'm fortunately not dependent on third-party libraries, few of which are there for Py3k yet. But they will be.

There is nothing wrong with using 2.6 - 2.7 will come and be even more of a bridge to 3.x, and you can start generating Py3k-like code already that will be trivial to port to 3.x once your favorite third-party library is there. I think I read somewhere that Py2k will be around for several more years.

Answer 3

Since Python 3K is not backwards compatible, you can expect that it will take more time to be accepted in corporate environments. Python has a huge code base and many important third libraries. One must wait for all dependencies to be converted to Python 3K before adopting it. This could be a real slow process.

From what I understand, the creators of Python expected this to happen, but they thought it will be worse not to make the changes and just let the language "die".

Answer 4

Python 3.x is not yet aimed at production use, but it will get there in time.

As a language and a runtime, Python 3.x is fine. The limitation is that a lot of important third party libraries and tools are still in the process of being ported and tested.

It is expected that the transition to Python 3.x will take up to five years.

So, if you are not library developer, you really don't need to care about Python 3.x for the time being.

Also, it is not expected of current Python users to do the switch to Python 3.x anytime soon.

Answer 5

There are a lot of libraries which depend on other libraries in the Python ecosystem. Nose is used to test numpy, and scipy requires numpy, and lots of scientific libraries require scipy. Also, none of the library developers can start porting until their dependencies are ported. It's going to take a long time for whole chain to port across.

A lot of the pragmatists are hoping that python 2.7 and 2.8 will gradually depreciate the bits that won't work in python 3 (introduce a print function called print_function, then depreciate the print statement, then rename print_function to print ...), so eventually python 2 will merge with python 3.

Answer 6

The OP appears to be surprised that a minor-release upgrade (which added some nifty features, basically broke zero existing code, and allowed trivial rebuilds of all existing third party libraries) happened overnight at their organization, while a major-release upgrade (requiring much more effort especially from the point of view of third-party library authors) didn't and won't. I think I mostly feel surprised at their surprise;-).

Even minor-release upgrades don't happen instantly in most large projects and organizations; for example, App Engine is still using Python 2.5 (apparently, upgrading its specialized "sandboxed" Python runtime and all it relies on is not a zero-effort proposition, so they prefer to keep putting their energy towards adding engine features instead) -- so I believe are implementations such as Jython and PyPy (I think IronPython's in the process of migrating to 2.6, but the current production version is still 2.5).

Totally new projects starting today should seriously consider starting with Python 3; for example, Allison Randal's pynie (Python for Parrot) project made exactly that choice (and, I think, it was the correct choice in their situation). Migrating existing projects is a harder proposition, and mostly depends on what third-party components the existing project depends on (if a new project intrinsically depends on some functionality that's only available in 3rd party libraries for 2.6, not 3.1, then the new project will probably also have to stick with the 2.6 version for the time being, of course).

Third party libraries that are under active development will probably come out with Python 3 version gradually (for example, gmpy did so relatively recently). Once enough such third party libraries are available, the chance that a missing library inhibits migrating an existing project (or, even more, starting a new project) using Python 3 starts going down pretty rapidly. This makes Python 3 ports feasible. At some point, some attractive functionality will become available in Python 3 only (for example, if and when pynie releases, that might be the case for a Parrot implementation affording smooth interoperability with Perl &c), and that will provide a strong motivation for some projects to go 3-only (pragmatically stronger than pure issues of language quality).

Even then, some sufficiently large projects and organizations will stick with Python 2 for a long time, and you can confidently expect that at some time a 2.7 will exist (possibly one or two more after that, but that's harder to predict). Hey, I sharply remember that throughout the '90s in most large projects and organizations "Fortran" still meant Fortran 77 (in fact in some places -- not many, 30+ years after than Fortran version's first release -- that's still true today!)... for all the advantages of Fortran 90 and later versions, migration costs (esp. in terms of various compilers, libraries, tools) were just perceived as being too high a price to pay for the advantages of the new language version. That's just inevitable when a language acquires a large installed base and a rich ecosystem of third party tools and libraries, as Python 2 now has. No reason for surprise!-)

Answer 7

Here is a video there Guido van Rossum, at the Py4Science meeting, talks about Python 3. http://fperez.org/py4science/2009_guido_ucb/index.html