3 ms·

Devil's advocate: Many people aren't even bothered to try. The company I work for still writes new stuff in Python _2.7.3_ - not even a recent release of 2.7.

Devil's advocate: Many people aren't even bothered to try. The company I work for still writes new stuff in Python _2.7.3_ - not even a recent release of 2.7. Some of their stuff will be difficult to convert, but a lot of it really is trivial. They just don't care to put any effort into it until things start to break down. I can understand why people get frustrated by situations like this and are tempted to call out programs still running Python 2 and those who advocate for keeping it. I'm a huge fan of some of the features introduced by Python 3, so I switched and am not interested in going back. However, I think there is room for other interpreters to step in and continue supporting Python 2 even if the PSF wont.

londons_explore 7y ago
Google?
strenholme 7y ago
If I were in that situation, I would make a reasonable effort to keep scripts as polyglots: Make sure they both run in Python 2 and in Python 3. In my experience, doing so is pretty easy to do when writing new code from scratch with Python 3 compatibility in mind. The “no one is maintaining Python 2” issue is an example of open source economics in action: Everyone wants Python2 to be maintained, but no one is stepping up to plate to pay for it to be maintained, so it’s not getting maintained.
Izkata 7y ago
> Python _2.7.3_ Familiar number. Maybe they tried, and stuff broke in weird and unexpected ways, so they gave up. For example, the first time we upgraded from that to (I think) .8, lots of strange errors started coming in from our webapp. Apparently kombu, one of the dependencies of celery, was importing an underscore-function from the standard library, which no longer existed in the new version.
- CivBase 7y ago
  This is definitely the case for a few apps. It's why I raise hell anytime I see someone use a private attribute or function from a builtin module. However, I'm painfully aware that it does not apply to most of our apps and it does not justify using an outdated interpreter for writing new apps.
  - strenholme 7y ago
    There are occasional cases where, with some Python libraries, I need to use a “hidden” _function to do my job. The one time I had to do that, I made sure to contact the authors to let them know what I did and why: https://github.com/cobrateam/splinter/issues/591 https://github.com/cobrateam/splinter/issues/591

londons_explore 7y ago

Google?

strenholme 7y ago

If I were in that situation, I would make a reasonable effort to keep scripts as polyglots: Make sure they both run in Python 2 and in Python 3. In my experience, doing so is pretty easy to do when writing new code from scratch with Python 3 compatibility in mind. The “no one is maintaining Python 2” issue is an example of open source economics in action: Everyone wants Python2 to be maintained, but no one is stepping up to plate to pay for it to be maintained, so it’s not getting maintained.

Izkata 7y ago

> Python _2.7.3_ Familiar number. Maybe they tried, and stuff broke in weird and unexpected ways, so they gave up. For example, the first time we upgraded from that to (I think) .8, lots of strange errors started coming in from our webapp. Apparently kombu, one of the dependencies of celery, was importing an underscore-function from the standard library, which no longer existed in the new version.

CivBase 7y ago
This is definitely the case for a few apps. It's why I raise hell anytime I see someone use a private attribute or function from a builtin module. However, I'm painfully aware that it does not apply to most of our apps and it does not justify using an outdated interpreter for writing new apps.
- strenholme 7y ago
  There are occasional cases where, with some Python libraries, I need to use a “hidden” _function to do my job. The one time I had to do that, I made sure to contact the authors to let them know what I did and why: https://github.com/cobrateam/splinter/issues/591 https://github.com/cobrateam/splinter/issues/591