4 ms·

We have several large projects that are written in Python. Most of these aee production applications that are critical to what we do, and the others are librar

We have several large projects that are written in Python. Most of these aee production applications that are critical to what we do, and the others are libraries and tools for internal work. We haven't even started thinking about porting these to python3. We have so many other things to worry about (but fixes, new features, etc) that it's hard to justify the time investment to port these now. I can't imagine we're the only ones in this situation.

int_19h 10y ago
You're not, of course. And there are similarly many people running production critical code written in Perl 5 on RedHat 9 or something like that. "If it's not broken, don't touch it" is a wise rule to follow for that kind of stuff. But to keep it running, you don't really need Python 2.8 with new features, right? You need extended support for Python 2.7 - basically, making sure that it keeps working with updated versions of other software (like OSes), and that bugs are fixed.
- coldtea 10y ago
  >But to keep it running, you don't really need Python 2.8 with new features, right? You need extended support for Python 2.7 - basically, making sure that it keeps working with updated versions of other software (like OSes), and that bugs are fixed. Those systems are not just sitting there untouched. Heck, not even 70s COBOL systems are "just sitting there" (they are hooked to newer systems, get new forms, have alterations, etc. all the time), and those Python 2.7 systems have been written 10-15 years before or less. And they continue to get new subsystems, new features, alterations, etc. In 2.7. So, yes, people would very much like to get not just "extended support for 2.7" but also the ability to keep running it in newer versions, and be able to take piecemeal adoption of new features to make their life better and eventually organically refactor in their own timeline.

int_19h 10y ago

You're not, of course. And there are similarly many people running production critical code written in Perl 5 on RedHat 9 or something like that. "If it's not broken, don't touch it" is a wise rule to follow for that kind of stuff. But to keep it running, you don't really need Python 2.8 with new features, right? You need extended support for Python 2.7 - basically, making sure that it keeps working with updated versions of other software (like OSes), and that bugs are fixed.

coldtea 10y ago
>But to keep it running, you don't really need Python 2.8 with new features, right? You need extended support for Python 2.7 - basically, making sure that it keeps working with updated versions of other software (like OSes), and that bugs are fixed. Those systems are not just sitting there untouched. Heck, not even 70s COBOL systems are "just sitting there" (they are hooked to newer systems, get new forms, have alterations, etc. all the time), and those Python 2.7 systems have been written 10-15 years before or less. And they continue to get new subsystems, new features, alterations, etc. In 2.7. So, yes, people would very much like to get not just "extended support for 2.7" but also the ability to keep running it in newer versions, and be able to take piecemeal adoption of new features to make their life better and eventually organically refactor in their own timeline.