12 ms·

Python 2 isn't going anywhere anytime soon. Tools and libraries which drop support for Python 2 will suffer and will either revert their decision or be replaced

Python 2 isn't going anywhere anytime soon. Tools and libraries which drop support for Python 2 will suffer and will either revert their decision or be replaced with something else.

Cyph0n 10y ago
Found the Python 2 developer folks! Joking aside, Python 3 is the only Python. The only people who should use Python 2 are those supporting legacy codebases, and even they should start migrating.
- andybak 10y ago
  Tricky one. I've just had to sell my clients on an update from Django < 1.8 as that fell out of it's support period. "Hey folks. I've got to do lots of work that will result in no new visible functionality and I'd like to be paid for it" I did consider slipping a Python 3 upgrade in there at the same time but there are limits to my powers of persuasion. So - Python 3 will have to wait.
  - cuu508 10y ago
    How about car oil changes for an analogy? You could probably drive for several oil change periods without apparent issues, until eventually there would be big issues. Django upgrades are similar, not "that" difficult, and it's a good idea not to fall too far back in versions, running into more and more incompatibilities. Py 2 -> 3 is a bigger one, so maybe like a timing belt change? ;-)
  - jsmeaton 10y ago
    I don't do this kind of work (agency) but I find it strange that ongoing maintenance isn't discussed and priced into the statement of work right from the beginning. Something like 2 days maintenance every 9 months to stay current, or 4 days every 2-3 years to go from LTS to LTS. If a customer doesn't understand why they need to be paying maintenance every x months or years, isn't that your fault for not making that clear in the beginning? Sorry if it seems like I'm picking on you, but I've seen this kind of comment quite a lot, and I've never asked the question before.
    - MyNameIsFred 10y ago
      I'm coming from the Java world, but as a consultant for enterprise customers, I'll say that they only understand two kinds of ongoing maintenance: 1. Dollars over time (e.g. licenses) 2. Purpose-specific hire (i.e. hire a guy to do nothing but support this new thing between now and forever) In other words, they understand continuous maintenance, but not continual maintenance. Anything else is either too awkward to write on a budget. If you suggest that it needs periodic review, they'll think you just need to "do it right the first time, so this isn't an issue going forward", whether or not that makes any sense.
    - andybak 10y ago
      I actually agree and I should factor that in more. However for many reasons it's often tricky: 1. This is something you have to address in the initial stages of a client relationship and with price-sensitive clients unused to software development if you're not careful it can sound like you're just rent-seeking. 2. 'Big but infrequent' changes are difficult to cost. Django LTS upgrades are every 5 years. Breaking changes like Python 2 to 3 are even rarer. What figure would I have proposed during the sales process that would have correctly covered me for these? I'm almost certain I would have significantly underestimated. 3. It's not always clear if you're entering into a long-term relationship with the client. They might expect the website to be completely replaced in a year or so, they might be intending to bring development in-house or various other things that make 'saving for a rainy day' a tricky proposition.
      - cowsandmilk 10y ago
        > 3. It's not always clear if you're entering into a long-term relationship with the client. I've also found that clients will often be acquired, go through management changes, etc that make having these things built in become unstable. One of my clients was acquired by Merck, then Merck sent a letter saying they were terminating all contracts. 18 months later, I get a frantic e-mail from some low-level people asking why I was no longer updating things for them. The median life of many companies makes building in release->release upgrade support difficult in practice.
      - jsmeaton 10y ago
- jdimov10 10y ago
  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.
- IanOzsvald 10y ago
  A few weeks back I surveyed my 3,500 members at PyDataLondon (London-based Python data scientists) about their Python version usage. At work 60% use Python 2.7, 33% use Python 3.4+. At home 44% use Python 2.7, 49% use Python 3.4+. I'm predicting 50% at-work usage of Python 3.4+ this time next year for my London community: http://ianozsvald.com/2016/06/20/results-for-which-version-of-python-2vs3-do-london-data-scientists-use/ http://ianozsvald.com/2016/06/20/results-for-which-version-o... Note - I'm the co-chair for PyDataLondon (and the local conference series). I regularly poll my monthly meetup audience to see how many folk upgrade each month. Normally 1-10 per month stick their hand up, nobody sticks their hand up if I ask "how many downgraded from Python 3 this month?".
  - rbanffy 10y ago
    Many people use Python 2 for the sole reason it's the default system Python. I assume a lot of them will instantaneously move to Python 3 the moment typing "python" on the command line will invoke the Python 3 REPL. All my python 2 only code explicitly invokes python 2 on the shebang line.
    - collinmanderson 10y ago
      Though, more likely they'll find that typing "python" returns "command not found", and in that case they might find it easier to just type apt-get/dnf install python.
theseatoms 10y ago
> Python 2 isn't going anywhere anytime soon. This can be read two very different ways. ;)
- jdimov10 10y ago
  Good! Both apply.
fonnesbeck 10y ago
If you don't need Python 3, then you won't need IPython 6.

Python 2 isn't going anywhere anytime soon. Tools and libraries which drop support for Python 2 will suffer and will either revert their decision or be replaced with something else.

Cyph0n 10y ago

Found the Python 2 developer folks! Joking aside, Python 3 is the only Python. The only people who should use Python 2 are those supporting legacy codebases, and even they should start migrating.

andybak 10y ago
Tricky one. I've just had to sell my clients on an update from Django < 1.8 as that fell out of it's support period. "Hey folks. I've got to do lots of work that will result in no new visible functionality and I'd like to be paid for it" I did consider slipping a Python 3 upgrade in there at the same time but there are limits to my powers of persuasion. So - Python 3 will have to wait.
- cuu508 10y ago
  How about car oil changes for an analogy? You could probably drive for several oil change periods without apparent issues, until eventually there would be big issues. Django upgrades are similar, not "that" difficult, and it's a good idea not to fall too far back in versions, running into more and more incompatibilities. Py 2 -> 3 is a bigger one, so maybe like a timing belt change? ;-)
- jsmeaton 10y ago
  I don't do this kind of work (agency) but I find it strange that ongoing maintenance isn't discussed and priced into the statement of work right from the beginning. Something like 2 days maintenance every 9 months to stay current, or 4 days every 2-3 years to go from LTS to LTS. If a customer doesn't understand why they need to be paying maintenance every x months or years, isn't that your fault for not making that clear in the beginning? Sorry if it seems like I'm picking on you, but I've seen this kind of comment quite a lot, and I've never asked the question before.
  - MyNameIsFred 10y ago
    I'm coming from the Java world, but as a consultant for enterprise customers, I'll say that they only understand two kinds of ongoing maintenance: 1. Dollars over time (e.g. licenses) 2. Purpose-specific hire (i.e. hire a guy to do nothing but support this new thing between now and forever) In other words, they understand continuous maintenance, but not continual maintenance. Anything else is either too awkward to write on a budget. If you suggest that it needs periodic review, they'll think you just need to "do it right the first time, so this isn't an issue going forward", whether or not that makes any sense.
  - andybak 10y ago
    I actually agree and I should factor that in more. However for many reasons it's often tricky: 1. This is something you have to address in the initial stages of a client relationship and with price-sensitive clients unused to software development if you're not careful it can sound like you're just rent-seeking. 2. 'Big but infrequent' changes are difficult to cost. Django LTS upgrades are every 5 years. Breaking changes like Python 2 to 3 are even rarer. What figure would I have proposed during the sales process that would have correctly covered me for these? I'm almost certain I would have significantly underestimated. 3. It's not always clear if you're entering into a long-term relationship with the client. They might expect the website to be completely replaced in a year or so, they might be intending to bring development in-house or various other things that make 'saving for a rainy day' a tricky proposition.
    - cowsandmilk 10y ago
      > 3. It's not always clear if you're entering into a long-term relationship with the client. I've also found that clients will often be acquired, go through management changes, etc that make having these things built in become unstable. One of my clients was acquired by Merck, then Merck sent a letter saying they were terminating all contracts. 18 months later, I get a frantic e-mail from some low-level people asking why I was no longer updating things for them. The median life of many companies makes building in release->release upgrade support difficult in practice.
    - jsmeaton 10y ago
jdimov10 10y ago
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.
IanOzsvald 10y ago
A few weeks back I surveyed my 3,500 members at PyDataLondon (London-based Python data scientists) about their Python version usage. At work 60% use Python 2.7, 33% use Python 3.4+. At home 44% use Python 2.7, 49% use Python 3.4+. I'm predicting 50% at-work usage of Python 3.4+ this time next year for my London community: http://ianozsvald.com/2016/06/20/results-for-which-version-of-python-2vs3-do-london-data-scientists-use/ http://ianozsvald.com/2016/06/20/results-for-which-version-o... Note - I'm the co-chair for PyDataLondon (and the local conference series). I regularly poll my monthly meetup audience to see how many folk upgrade each month. Normally 1-10 per month stick their hand up, nobody sticks their hand up if I ask "how many downgraded from Python 3 this month?".
- rbanffy 10y ago
  Many people use Python 2 for the sole reason it's the default system Python. I assume a lot of them will instantaneously move to Python 3 the moment typing "python" on the command line will invoke the Python 3 REPL. All my python 2 only code explicitly invokes python 2 on the shebang line.
  - collinmanderson 10y ago
    Though, more likely they'll find that typing "python" returns "command not found", and in that case they might find it easier to just type apt-get/dnf install python.

theseatoms 10y ago

> Python 2 isn't going anywhere anytime soon. This can be read two very different ways. ;)

jdimov10 10y ago
Good! Both apply.

fonnesbeck 10y ago

If you don't need Python 3, then you won't need IPython 6.