4 ms·

This is fine as far as wishful thinking goes, but simply doesn't correspond to reality. Over the past 15 years or so I have been working with and consulting lar

This is fine as far as wishful thinking goes, but simply doesn't correspond to reality. Over the past 15 years or so I have been working with and consulting large corporations using Python, all over the world. And I can tell you for a fact: Python 3 is simply not an option in most cases. I HAVE worked on transitioning several large codebases from 2 to 3 and in each case this has been months of work, incurring completely unjustified costs. The benefits have been practically negligible. I would never advise a client with an existing codebase to move on to Python 3, unless there were damn good reasons for it. For new, smaller projects, that don't have too many external dependencies - Python 3 is fine. Again, even in these cases, the benefits are largely superficial.

orf 10y ago
> I HAVE worked on transitioning several large codebases from 2 to 3 and in each case this has been months of work, incurring completely unjustified costs Out of interest whats the biggest time sink while doing this? I've had a lot of luck using 2to3 and with decent test coverage and a UAT environment that people can access, its not exactly months and months of work changing "xrange" to "range", and "print" to "print()"
- avian 10y ago
  > decent test coverage You were indeed very lucky if all projects you've worked on had decent test coverage.
- crdoconnor 10y ago
  For me it's been libraries which we rely upon which don't support 3.
  - wiz21c 10y ago
    care to give some examples ?
  - orf 10y ago
    True, I didn't consider the cost of updating packages (and any associated API changes). But in my experience there are very few packages that simply don't support Python 3, and the ones that don't are just dead.
  - ATsch 10y ago
    http://py3readiness.org http://py3readiness.org looks pretty good, most of the blockers for me (like twisted and a few others) are gone by now.
- nas 10y ago
  The unicode/bytes change it the most time consuming in my experience. Second comes the fact that you can't sort arbitrary types anymore and that None is no longer smaller than any other value. In order to ease porting, I've created a modified Python 3.6 interpreter that generates warnings in a lot of the cases that real Python 3 would generate an exception. See https://github.com/nascheme/ppython https://github.com/nascheme/ppython . The goal is to have a 2to3 script that generates something that will run, with warnings, under me modified Python. Once you fix all the warnings, your code should run correctly in Python 3.
  - orf 10y ago
    > Second comes the fact that you can't sort arbitrary types anymore Surely that's a bug in the system that you've just uncovered and fixed? Py2 used to use the memory address of the object when comparing by default, which is just... crazy, especially for a language with so few WTFs: >>> object() > object() True >>> object() > object() False >>> object() > object() True >>> object() > object() False > In order to ease porting, I've created a modified Python 3.6 interpreter That looks amazing! We're going to end up porting a fairly large + critical Django app to py3 and I definitely think this could ease some of the pain. I'm going to give it a go when I get the chance.
    - dragonwriter 10y ago
      > Py2 used to use the memory address of the object when comparing by default, which is just... crazy, Its true that that's crazy, but, OTOH, everything-can-be-sorted is a useful feature (which Erlang has, for instance). Py3 could conceptually have retained it with a different implementation (this would probably still have been a breaking change from Py2, but not a feature loss.)
deleted 10y ago
[deleted]
melling 10y ago
Python 2.x support ends in 4 years. It seems irresponsible to not be planning for a move now. Large firms do take longer but that's why now is a good time to begin. The cost is justified if you want to use a supported language.
- jdimov10 10y ago
  I can't think of a way that this makes any difference, or see any reason why anyone should be bothered by python 2 support "ending". I don't even understand what this means, I mean it sounds like a scare tactic without substance. At the end of the day, if the PSF won't support it, I will (and I'll happily take the money for it).
  - melling 10y ago
    Big companies aren't going to gamble their future without support. And they probably don't want to deal with a single guy they find on the Internet for security/bug fixes in a forked version of Python.
    - jdimov10 10y ago
      Your guesses are wrong. Obviously when I say "I will support it", I don't mean myself, single-handedly. I mean my company. Or someone else's company. The point is, commercially speaking, nobody cares about official PSF support. The world will go on unaffected, with or without it.
      - MyNameIsFred 10y ago
        I'm not saying you're wrong, but I find that very surprising. It's a far cry from the Enterprise Java consultant world I live in.
        cstejerean 10y ago
        Sure, but PSF is not the equivalent of Oracle. If someone wanted a big enterprise to provide support they would use a language from a big enterprise. The difference between the PSF and another small company stepping up to provide support is negligible.
wiz21c 10y ago
unicode. That in itself is a huge win for the kind of the stuff I work on (100000LOC sized project). It makes things so much easier.
- cschmidt 10y ago
  Absolutely. If you live in a world of ascii, then maybe python 2 is adequate. But I always deal with unicode, and python 3 is a big benefit just for that.
carreau 10y ago
Making new release of Open-Source & free library python 3 only does not prevent your clients to still use the old versions. Those will never become incompatible. If the want longer support they then can consider giving some money to the Open-Source project they use. The switching at this point for many of the libraries/project that make these decision is almost 0 cost, and number of benefits. Especially when these libraries are maintained by Night and Week-end contributors. I think many contributors to these library would love to be hired to work on it, and many of these library would love8 to get funding to hire their contributor. I'm actually seating to 2 of these people that were hired by such kind of funds, and are now looking for more funding to hire more dev. Saying new versions will not be Python 2 compatible is not a request for Companies to upgrades. It's just a statement that they will be stuck on old version of libraries, unless they buy* support for a vendor. We (the IPython team) have no objection if Continuum or Enthought provide a Paying version of IPython 6.x that is Python 2 compatible, but that's their problem. It does not prevent either the core developer of the Python-3 only project to consult on potential Python 2 internal fork. I honestly think that this would be a much sane model that would make both sides of the Py2vsPy3 battle happy.
spott 10y ago
>I would never advise a client with an existing codebase to move on to Python 3, unless there were damn good reasons for it. The end of life of python 2, and the end of python 2 support in popular libraries isn't "a damn good reason"?

orf 10y ago

> I HAVE worked on transitioning several large codebases from 2 to 3 and in each case this has been months of work, incurring completely unjustified costs Out of interest whats the biggest time sink while doing this? I've had a lot of luck using 2to3 and with decent test coverage and a UAT environment that people can access, its not exactly months and months of work changing "xrange" to "range", and "print" to "print()"

avian 10y ago
> decent test coverage You were indeed very lucky if all projects you've worked on had decent test coverage.
crdoconnor 10y ago
For me it's been libraries which we rely upon which don't support 3.
- wiz21c 10y ago
  care to give some examples ?
- orf 10y ago
  True, I didn't consider the cost of updating packages (and any associated API changes). But in my experience there are very few packages that simply don't support Python 3, and the ones that don't are just dead.
- ATsch 10y ago
  http://py3readiness.org http://py3readiness.org looks pretty good, most of the blockers for me (like twisted and a few others) are gone by now.
nas 10y ago
The unicode/bytes change it the most time consuming in my experience. Second comes the fact that you can't sort arbitrary types anymore and that None is no longer smaller than any other value. In order to ease porting, I've created a modified Python 3.6 interpreter that generates warnings in a lot of the cases that real Python 3 would generate an exception. See https://github.com/nascheme/ppython https://github.com/nascheme/ppython . The goal is to have a 2to3 script that generates something that will run, with warnings, under me modified Python. Once you fix all the warnings, your code should run correctly in Python 3.
- orf 10y ago
  > Second comes the fact that you can't sort arbitrary types anymore Surely that's a bug in the system that you've just uncovered and fixed? Py2 used to use the memory address of the object when comparing by default, which is just... crazy, especially for a language with so few WTFs: >>> object() > object() True >>> object() > object() False >>> object() > object() True >>> object() > object() False > In order to ease porting, I've created a modified Python 3.6 interpreter That looks amazing! We're going to end up porting a fairly large + critical Django app to py3 and I definitely think this could ease some of the pain. I'm going to give it a go when I get the chance.
  - dragonwriter 10y ago
    > Py2 used to use the memory address of the object when comparing by default, which is just... crazy, Its true that that's crazy, but, OTOH, everything-can-be-sorted is a useful feature (which Erlang has, for instance). Py3 could conceptually have retained it with a different implementation (this would probably still have been a breaking change from Py2, but not a feature loss.)

deleted 10y ago

[deleted]

melling 10y ago

Python 2.x support ends in 4 years. It seems irresponsible to not be planning for a move now. Large firms do take longer but that's why now is a good time to begin. The cost is justified if you want to use a supported language.

jdimov10 10y ago
I can't think of a way that this makes any difference, or see any reason why anyone should be bothered by python 2 support "ending". I don't even understand what this means, I mean it sounds like a scare tactic without substance. At the end of the day, if the PSF won't support it, I will (and I'll happily take the money for it).
- melling 10y ago
  Big companies aren't going to gamble their future without support. And they probably don't want to deal with a single guy they find on the Internet for security/bug fixes in a forked version of Python.
  - jdimov10 10y ago
    Your guesses are wrong. Obviously when I say "I will support it", I don't mean myself, single-handedly. I mean my company. Or someone else's company. The point is, commercially speaking, nobody cares about official PSF support. The world will go on unaffected, with or without it.
    - MyNameIsFred 10y ago
      I'm not saying you're wrong, but I find that very surprising. It's a far cry from the Enterprise Java consultant world I live in.
      - cstejerean 10y ago
        Sure, but PSF is not the equivalent of Oracle. If someone wanted a big enterprise to provide support they would use a language from a big enterprise. The difference between the PSF and another small company stepping up to provide support is negligible.

wiz21c 10y ago

unicode. That in itself is a huge win for the kind of the stuff I work on (100000LOC sized project). It makes things so much easier.

cschmidt 10y ago
Absolutely. If you live in a world of ascii, then maybe python 2 is adequate. But I always deal with unicode, and python 3 is a big benefit just for that.

carreau 10y ago

Making new release of Open-Source & free library python 3 only does not prevent your clients to still use the old versions. Those will never become incompatible. If the want longer support they then can consider giving some money to the Open-Source project they use. The switching at this point for many of the libraries/project that make these decision is almost 0 cost, and number of benefits. Especially when these libraries are maintained by Night and Week-end contributors. I think many contributors to these library would love to be hired to work on it, and many of these library would love8 to get funding to hire their contributor. I'm actually seating to 2 of these people that were hired by such kind of funds, and are now looking for more funding to hire more dev. Saying new versions will not be Python 2 compatible is not a request for Companies to upgrades. It's just a statement that they will be stuck on old version of libraries, unless they buy* support for a vendor. We (the IPython team) have no objection if Continuum or Enthought provide a Paying version of IPython 6.x that is Python 2 compatible, but that's their problem. It does not prevent either the core developer of the Python-3 only project to consult on potential Python 2 internal fork. I honestly think that this would be a much sane model that would make both sides of the Py2vsPy3 battle happy.

spott 10y ago

>I would never advise a client with an existing codebase to move on to Python 3, unless there were damn good reasons for it. The end of life of python 2, and the end of python 2 support in popular libraries isn't "a damn good reason"?