[jdimov10]

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.

[carreau]

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.

[orf]

> 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]

> decent test coverage

You were indeed very lucky if all projects you've worked on had decent test coverage.

[nas]

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 .

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]

> 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]

> 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.)

[crdoconnor]

For me it's been libraries which we rely upon which don't support 3.

[orf]

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]

http://py3readiness.org looks pretty good, most of the blockers for me (like twisted and a few others) are gone by now.

[wiz21c]

care to give some examples ?

[wiz21c]

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]

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.

[spott]

>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"?

[melling]

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]

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]

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]

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.

[takluyver]

And you're welcome to support IPython and matplotlib on Python 2 at the same time. We're just saying we're not going to do that, in the same way that the PSF will stop supporting Python 2. At some point, the cost of third party support outweighs the cost of moving to Python 3.

[melling]

Can you clarify? Will these companies open source their support? Making a case for sticking with 2.x will be easier if there's one "official" repo. Otherwise, the number of patches and forks could quickly get out of hand.

[MyNameIsFred]

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]

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.