[coldtea]

What if a company has a large codebase that's in Python 2 and wants http2? Will those suggesting porting help them bear the costs and manhours it takes?

(Google, for one, still uses 2. As does Dropbox. And both companies had Guido Van Rossum working for them at some point).

[ellisv]

> What if a company has a large codebase that's in Python 2 and wants http2? Will those suggesting porting help them bear the costs and manhours it takes?

This is why banks still use COBOL and Fortran.

[coldtea]

More power to them!

[goatlover]

Companies are going to have to port at some point.

[brudgers]

Google has Grumpy. Because writing a compiler is easier than porting. https://github.com/google/grumpy

[enitihas]

Not sure about that. Some companies may have codebases as complicated as the python codebase itself. For them it may make more sense to maintain python2 than to upgrade. Granted, there will be very few such companies.

[CJefferson]

Python 2 is popular enough that someone will keep up support for decades to come. Just making sure it supports new OS releases, and fixing the occasional bug, will not be a significant overhead.

[kbutler]

Unjustifiable assertion.

  - they could continue to maintain python2
  - they could move to a non-python platform
  - they could go out of business
  - they could hold out for Python4 (Python3 was only 8 years after Python2)
  ...

[kevinmgranger]

GVR has already said that Python 4 (if it's even ever called that) will not have the same kind of breaking changes 3 did.

[kbutler]

And 3 had different changes than 2 (https://docs.python.org/3/whatsnew/2.0.html) though it is interesting that Unicode support was a big feature in both, and that many people still find Python3’s Unicode support problematic (e.g., http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/)

But if an individual or organization does not find the python 3 updates and ecosystem a compelling upgrade over 2, “don’t update until the next big change” is definitely one option.

[kevinmgranger]

The whole point of my comment is that there won't be a "next big change", just lots of smaller ones.

[devy]

All aforementioned large companies have a diverse tech stack rather than a single stack, let alone programming language versions. Having Python BDFL working for them doesn't necessarily mean they will follow Python community consensus. Neither was Guido tasked to help them upgrade their python stack to 3.x AFAIK.

Python core team will eventually cease support 2.x support at some point[1], so the ones who uses 2.x will be on their own. Will the cost of self-patching python 2.x lower than rewrite the software application you developed on 2.x? Well, that's on them to decide. After 2.x being officially deprecated, what's the point of having a Async HTTP/2 client working (mostly back-porting features that's already on 3k) on 2.x?

[1]: https://pythonclock.org/

[always_good]

> After 2.x being officially deprecated, what's the point of having a Async HTTP/2 client working (mostly back-porting features that's already on 3k) on 2.x?

Once again, the point is that software will continue working beyond that deprecation event.

As you said, the cost/benefit analysis of a rewrite isn't always in favor of a rewrite at that point in time. So what must follow is that there will be Python 2 software out in the wild for some time regardless of support. What other possibility is there?

[devy]

> Once again, the point is that software will continue working beyond that deprecation event.

Yes, python 2.x code will work - but in the event major CVEs for a piece of software stack that's deprecated, you are left to no choice but to fix on your own. Those sometime are by no means no small feat! And mind you this is an ongoing battle to patch up security holes.