4 ms·

If Python 3 is so wonderful, why are the Python 3 developers still using Python 2 in their toolchain? It's because it would reportedly take 1 man year to port M

If Python 3 is so wonderful, why are the Python 3 developers still using Python 2 in their toolchain? It's because it would reportedly take 1 man year to port Mercurial to Python 3. 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.

melling 12y ago
At this point, shouldn't organizations have a Python 3 plan? Legacy support ends in 5 years. Shouldn't new apps be written in 3 when possible?
- cabalamat 12y ago
  > Legacy support ends in 5 years. 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.
  - melling 12y ago
    2014 + 5 years? Should your company fire you if you're wrong about an extension to 2025? You're going to cost them a lot of technical debt. 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?
jsmeaton 12y ago
> It's because it would reportedly take 1 man year to port Mercurial to Python 3. 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.
- cabalamat 12y ago
  >> It's because it would reportedly take 1 man year to port Mercurial to Python 3. > 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 http://mercurial.selenic.com/wiki/SupportedPythonVersions
  - abuddy 12y ago
    - They don't mention in the presentation that you should port your current projects to 3.x Use it for your new projects. - 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.
bpicolo 12y ago
This is why web companies need to use service-based infrastructures. : ) It allows you to be agile about technologies without porting the world.
ayrx 12y ago
If Go is so awesome, why are Go developers still using C in their toolchain? 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.
pekk 12y ago
How long would it take to port Mercurial to Go? 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.
ekimekim 12y ago
Because the auto-unicode of system interfaces is a PITA if you want to deal with opaque data which is either binary or an unknown encoding? 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.
jlarocco 12y ago
That argument makes no sense. 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.
briancurtin 12y ago
> If Python 3 is so wonderful, why are the Python 3 developers still using Python 2 in their toolchain? It's because it would reportedly take 1 man year to port Mercurial to Python 3. 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).
- tshepang 12y ago
  What are some of the indicators that core devs have more interest in git than they did back then?
  - briancurtin 12y ago
    Conversations at the language summit, mostly. A lot more of us use git more often than we do hg these days as well.
    - tshepang 12y ago
      Wasn't aware. Good to know, thanks.

melling 12y ago

At this point, shouldn't organizations have a Python 3 plan? Legacy support ends in 5 years. Shouldn't new apps be written in 3 when possible?

cabalamat 12y ago
> Legacy support ends in 5 years. 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.
- melling 12y ago
  2014 + 5 years? Should your company fire you if you're wrong about an extension to 2025? You're going to cost them a lot of technical debt. 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?

jsmeaton 12y ago

> It's because it would reportedly take 1 man year to port Mercurial to Python 3. 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.

cabalamat 12y ago
>> It's because it would reportedly take 1 man year to port Mercurial to Python 3. > 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 http://mercurial.selenic.com/wiki/SupportedPythonVersions
- abuddy 12y ago
  - They don't mention in the presentation that you should port your current projects to 3.x Use it for your new projects. - 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.

bpicolo 12y ago

This is why web companies need to use service-based infrastructures. : ) It allows you to be agile about technologies without porting the world.

ayrx 12y ago

If Go is so awesome, why are Go developers still using C in their toolchain? 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.

pekk 12y ago

How long would it take to port Mercurial to Go? 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.

ekimekim 12y ago

Because the auto-unicode of system interfaces is a PITA if you want to deal with opaque data which is either binary or an unknown encoding? 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.

jlarocco 12y ago

That argument makes no sense. 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.

briancurtin 12y ago

> If Python 3 is so wonderful, why are the Python 3 developers still using Python 2 in their toolchain? It's because it would reportedly take 1 man year to port Mercurial to Python 3. 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).

tshepang 12y ago
What are some of the indicators that core devs have more interest in git than they did back then?
- briancurtin 12y ago
  Conversations at the language summit, mostly. A lot more of us use git more often than we do hg these days as well.
  - tshepang 12y ago
    Wasn't aware. Good to know, thanks.