If an organisation has lots of legacy Python code, it'll cost them a lot of effort to re-write it for Python 3, and for what? Programmers might be maybe 1% more productive in the new language than the old one. For most organisations, this would not make business sense.
That's a terrible argument. Of course it takes effort to port existing application and tools. In some cases, it might be worth it and in some cases, it might not be. Python 2.7 will always be available to run such tools and applications.
This is very different from the case of library developers that should port their libraries to Python 3 (or support both Python 2 and 3, this is not difficult) so that it's accessible to more code.
This isn't an argument at all when it comes to writing new stuff in Python 3.
Mercurial isn't part of Python, and is essentially a black box tool. We use mercurial for a C++ project at work. Does that make it a Python and C++ project? Obviously not.
You might as well argue that if Python3 were so great the devs wouldn't be using C and C++ in their toolchain, which is what most of the underlying operating system and tools are written in.
And in that case, the argument would apply to almost every language and implementation out there.
Because the incompatibility of unicode and bytes (b'x' != 'x') and the "everything must be unicode" dogma of the ecosystem make it impossible to use many libraries that previously worked just fine ignoring any non-ascii characters?
If nothing else, because it's really really annoying to have to write "b" in front of every string literal just so I'm actually dealing with strings, not text?
Unicode-by-default may be dandy for a web developer, but for using python for system applications and glue logic it just makes things difficult.
I will never move to python3 for as long as they've broken strings.
Source?
> If an organisation has lots of legacy Python code, it'll cost them a lot of effort to re-write it for Python 3, and for what?
No need to port code that doesn't get a lot of attention. But if you want new features of Python, then you just have to bite the bullet. Organisations upgrade hardware all the time. They upgrade their OS somewhat regularly (on the order of years, but still). You get to make a choice - stay current and supported, or don't.
As for me, I will be (and have been) writing new applications with python 3. But I still maintain and support a number of 2.7 apps which will probably never be upgraded.
> Source?
Python 3.x has proven notoriously difficult to support, due to our pervasive dependence on a byte-based encoding strategy and string manipulation. We have invested a substantial amount of time into porting at this point and we estimate at least a person-year of core developer time to make a full 3.x-compatible version.
-- http://mercurial.selenic.com/wiki/SupportedPythonVersions
- It would take a lot of time for Mercurial team because they work with files and have to support a lot of cases, encodings and stuff. Python 3 does a lot for the developer now.
- Mercurial is not the best example because you aren't supposed to use their internal API anyway. It's their choice to port it to 3 or not.
Why would that have anything to do with it? We didn't write it and don't have any input into Mercurial, and it works fine for what it's used for right now. It's a source control tool, not a library we use in any way.
If we did the subversion switch today, it'd be to git, which again has nothing to do with Python versions (obviously).
It allows you to be agile about technologies without porting the world.
Code which is costly to port won't be ported to anything, it will just sit there in its current state unless someone decides to port it.
Really? Support for Python 2.7 was going to end in 2015, but they recently extended it to 2020.
What's the betting that in 2019 they won't extend it to 2025, followed shortly after by quietly dropping python 3 (or someone forking 2.7 to produce a compatible 2.8).
> Shouldn't new apps be written in 3 when possible?
There are no compelling reasons (for me at least) to change to what is in fact a different language which happens to use the same name.
When the Python 3 people eat their own dogfood by using a Python 3 toolchain, I might reconsider.
I always wondered how we got to the Y2K problem. That was a pretty hard deadline and people knew it was coming for years. How do people get away with creating problems like this?