7 ms·

> python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done. Good for you. Some of us had code bases of considerable size and com

> python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done. Good for you. Some of us had code bases of considerable size and complexity though. The fact is that for working software on the python platform, this upgrade represented work that had to be done that for a legacy app that was still chugging... little benefit. If you already coded around the python 2 limitations for Unicode eg, then python 3 was not a help at that point for something already in service. It was just more cost for no benefit. > If people spent half as much energy upgrading as complaining, this would have gotten done 5 years ago. These aren’t exchangeable. Why do people on the internet think bitching (either constructive or not) is some valuable currency? Often times the people complaining had no means or position to of the work. 4 promotions later I sure as hell wasn’t going to participate in that 2 to 3 mess on a project produced years ago, but I could still opine in the situation. I also had little incentive to fund it. Your analogies are bizarre. No idea what you’re trying to convey with philips v torx but I’m going to wager it’s explanatory power in this case is shit anyway. I can still demolish it, having actually worked in manufacturing there were times we told a supplier (ie Python) to fuck off and piss up a rope because what they were proposing was not compatible with our existing tooling and it would be too costly to convert for little benefit to us. I respect apples prowess in the consumer space, but there’s a reason you don’t see their products regularly put into industrial roles where your timeline is more than 5 years. Apple products are disposable, many applications in industry are expected to last. Python is a general purpose programming language (or at least billed itself as such). Your comparison is poor.

mffnbs 7y ago
Your argument ignores that 2.7 was held onto for a decade. Legacy applications did not hold back adoption.
- Kaiyou 7y ago
  Which still seems like a short period of time, considering timelines in engineering are to support a version for 60 years.
  - fwip 7y ago
    You can keep running Python 2 just like you keep your COBOL systems running, nobody's gonna stop you except common sense.
    - Kaiyou 7y ago
      Right, but in engineering it's kind of expected to get support for a version for at least 60 years. Software engineering is just really weird in that it moves so fast and nobody seems to care to break things.
      - joshuamorton 7y ago
        What free things are supported for 60 years in engineering applications? Name one.
        greglindahl 7y ago
        Fairly ancient Fortran compiles OK in open source compilers. Not quite 60 years old, yet, but it'll be there soon.
        TheRealKing 7y ago
        It's already >65 years old. The 65th birthday was this summer 2019.
      - ZWoz 7y ago
        They (in engineering general) aren't expected support something free though. Putting it another way: You can get you support with Python2, if you pay.
    - protomyth 7y ago
      IBM does quite a good job of making sure that COBOL is supported long term with all needed updates for many many years to come. Python 2 is not in that position.
brians 7y ago
I found some Unicode bugs in porting—and I get continued free security updates. Seems fair to me, and certainly not “no benefit”. I can keep on 2.7 as long as I like; nobody’s forcing me to port. Compare the situation with Java!
- arve0 7y ago
  > Compare the situation with Java! Isn’t that comparable to java? Oracle gives you paid security updates on version 8. You can keep using the previous version without security updates or migrate to OpenJDK 8, which have their own security group. More options, seems better to me.
- mypalmike 7y ago
  I like Python. But it loses in the upgrade comparison to Java. Existing Java code almost always just keeps working with new compilers and JVMs. And new JVMs tend to increase performance of your code for relatively little upgrade effort.
  - afiori 7y ago
    In my uninformed opinion not including a python 2 interpreter in python 3 was the first mistake
wiradikusuma 7y ago
I think this is where paid support comes into picture. Volenteers can keep improving Python, business that cant/wont upgrade can pay someone to "handle it", and consultants can make money. Everyone is happy.
- WorldMaker 7y ago
  The FAQ does point to vendors that plan to offer long time support/conversion paid support plans.
WilliamEdward 7y ago
You've managed to say their analogy is bad in two paragraphs without even explaining why it's a bad analogy. You even admit you don't really understand what they were trying to say. Poor explanation, or poor understanding?
- ofibrvev 7y ago
  If an analogy requires more explanation than the original concept what purpose does it serve? I think in this case at best the analogy grossly oversimplifies the issue. If it really were just a “screwdrivers” problem as explained then the 2 to 3 migration would have been mostly trouble free and would have happened. Clearly it did not go that way so that analogy can not possibly be appropriate.
djsumdog 7y ago
You have a dependency rot problem. Are you missing unit tests? Because having a ton of unit tests can reduce dependency rot, breakage and overall make engineering upgrades just a lot easier to deal with. They don't catch everything of course, but they can catch a lot. If you haven't put in the priority to update your Py2 to Py3 apps by now, I really think your shop has the wrong priorities. It's not just about Py2/3. Dependency rot is one of the worst form of technical debt. It often shows broken CI, broken security scanning, lots of generally broken processes that will just keep hurting a team further and further down the line.
- pfranz 7y ago
  I don't really agree with much of what the person you replied to said, but certain domains have had their hands tied and I also can't imagine them working as you describe. CG/Visual Effects industry is still firmly using Python 2. Only in 2020 are they taking the first step to transition to Py3 [1]. Users and studios are held back because the Python runtime is used inside major applications; Nuke, Houdini, Maya as well as libraries and APIs. None of them have released a version that runs Python 3 yet. The reasons for delaying it (mentioned in a footnote on that page) makes sense to me. Previous years were focusing on coordinating updates to GCC, Boost, C++14, Qt, and waiting on Python bindings for Qt. Also, I've worked at a couple studios many people have probably heard of and none of them have unit tests covering much of their code. The focus is on tools that facilitate in-house artists where responsiveness to needs are valued over architecture and completeness. Requirements change for each project and previous requirements are often sacrificed (until a new project needs them in a few years). I'm itching to move to Python3, but even for standalone tools I've felt it better to choose a completely different language (or Python2) instead trying to mix Python2 and 3 because having them co-exist creates more headaches in managing the environments, dependencies, and coding styles. [1] https://vfxplatform.com https://vfxplatform.com
- cortesoft 7y ago
  > If you haven't put in the priority to update your Py2 to Py3 apps by now, I really think your shop has the wrong priorities. I am not sure how you could possibly know this. You have no idea what else they were working on instead.
munificent 7y ago
The tone of your writing is rude, unpersuasive, and lowers the level of discourse on the forum.
- ofibrvev 7y ago
  That’s like, your opinion, man. I didn’t think it was the most amazing comment either, however, it was intended more to illustrate how things are rather than how they ought to be, I think some interpreted as a strong opinion in favor of the circumstances which was not intended. Based on how it scored (somewhat surprisingly) it clearly resonated with more than a few.

mffnbs 7y ago

Your argument ignores that 2.7 was held onto for a decade. Legacy applications did not hold back adoption.

Kaiyou 7y ago
Which still seems like a short period of time, considering timelines in engineering are to support a version for 60 years.
- fwip 7y ago
  You can keep running Python 2 just like you keep your COBOL systems running, nobody's gonna stop you except common sense.
  - Kaiyou 7y ago
    Right, but in engineering it's kind of expected to get support for a version for at least 60 years. Software engineering is just really weird in that it moves so fast and nobody seems to care to break things.
    - joshuamorton 7y ago
      What free things are supported for 60 years in engineering applications? Name one.
      - greglindahl 7y ago
        Fairly ancient Fortran compiles OK in open source compilers. Not quite 60 years old, yet, but it'll be there soon.
        TheRealKing 7y ago
        It's already >65 years old. The 65th birthday was this summer 2019.
    - ZWoz 7y ago
      They (in engineering general) aren't expected support something free though. Putting it another way: You can get you support with Python2, if you pay.
  - protomyth 7y ago
    IBM does quite a good job of making sure that COBOL is supported long term with all needed updates for many many years to come. Python 2 is not in that position.

brians 7y ago

I found some Unicode bugs in porting—and I get continued free security updates. Seems fair to me, and certainly not “no benefit”. I can keep on 2.7 as long as I like; nobody’s forcing me to port. Compare the situation with Java!

arve0 7y ago
> Compare the situation with Java! Isn’t that comparable to java? Oracle gives you paid security updates on version 8. You can keep using the previous version without security updates or migrate to OpenJDK 8, which have their own security group. More options, seems better to me.
mypalmike 7y ago
I like Python. But it loses in the upgrade comparison to Java. Existing Java code almost always just keeps working with new compilers and JVMs. And new JVMs tend to increase performance of your code for relatively little upgrade effort.
- afiori 7y ago
  In my uninformed opinion not including a python 2 interpreter in python 3 was the first mistake

wiradikusuma 7y ago

I think this is where paid support comes into picture. Volenteers can keep improving Python, business that cant/wont upgrade can pay someone to "handle it", and consultants can make money. Everyone is happy.

WorldMaker 7y ago
The FAQ does point to vendors that plan to offer long time support/conversion paid support plans.

WilliamEdward 7y ago

You've managed to say their analogy is bad in two paragraphs without even explaining why it's a bad analogy. You even admit you don't really understand what they were trying to say. Poor explanation, or poor understanding?

ofibrvev 7y ago
If an analogy requires more explanation than the original concept what purpose does it serve? I think in this case at best the analogy grossly oversimplifies the issue. If it really were just a “screwdrivers” problem as explained then the 2 to 3 migration would have been mostly trouble free and would have happened. Clearly it did not go that way so that analogy can not possibly be appropriate.

djsumdog 7y ago

You have a dependency rot problem. Are you missing unit tests? Because having a ton of unit tests can reduce dependency rot, breakage and overall make engineering upgrades just a lot easier to deal with. They don't catch everything of course, but they can catch a lot. If you haven't put in the priority to update your Py2 to Py3 apps by now, I really think your shop has the wrong priorities. It's not just about Py2/3. Dependency rot is one of the worst form of technical debt. It often shows broken CI, broken security scanning, lots of generally broken processes that will just keep hurting a team further and further down the line.

pfranz 7y ago
I don't really agree with much of what the person you replied to said, but certain domains have had their hands tied and I also can't imagine them working as you describe. CG/Visual Effects industry is still firmly using Python 2. Only in 2020 are they taking the first step to transition to Py3 [1]. Users and studios are held back because the Python runtime is used inside major applications; Nuke, Houdini, Maya as well as libraries and APIs. None of them have released a version that runs Python 3 yet. The reasons for delaying it (mentioned in a footnote on that page) makes sense to me. Previous years were focusing on coordinating updates to GCC, Boost, C++14, Qt, and waiting on Python bindings for Qt. Also, I've worked at a couple studios many people have probably heard of and none of them have unit tests covering much of their code. The focus is on tools that facilitate in-house artists where responsiveness to needs are valued over architecture and completeness. Requirements change for each project and previous requirements are often sacrificed (until a new project needs them in a few years). I'm itching to move to Python3, but even for standalone tools I've felt it better to choose a completely different language (or Python2) instead trying to mix Python2 and 3 because having them co-exist creates more headaches in managing the environments, dependencies, and coding styles. [1] https://vfxplatform.com https://vfxplatform.com
cortesoft 7y ago
> If you haven't put in the priority to update your Py2 to Py3 apps by now, I really think your shop has the wrong priorities. I am not sure how you could possibly know this. You have no idea what else they were working on instead.

munificent 7y ago

The tone of your writing is rude, unpersuasive, and lowers the level of discourse on the forum.

ofibrvev 7y ago
That’s like, your opinion, man. I didn’t think it was the most amazing comment either, however, it was intended more to illustrate how things are rather than how they ought to be, I think some interpreted as a strong opinion in favor of the circumstances which was not intended. Based on how it scored (somewhat surprisingly) it clearly resonated with more than a few.