10 ms·

Based on your timeline, a four year gap from "not yet ready to migrate" to "we won't fix security vulnerabilities" is very short. Python is an open source proj

Based on your timeline, a four year gap from "not yet ready to migrate" to "we won't fix security vulnerabilities" is very short. Python is an open source project I've used and contributed nothing to, so I don't have the right to be a back seat driver. Were it a commercial project and I was a customer, I would be quite upset.

PeterisP 7y ago
The thing is, a four year gap is very large from the perspective of "should we drop everything else and prioritize porting our library to python3 right now". If the deadline wasn't 2020 but 2024, then you wouldn't get more time, simply we'd be at "not yet ready to migrate" state right now, as major libraries would not have switched yet.
- hobofan 7y ago
  > porting our library Library, as is most open source libraries out there, sure. For a big company-internal Python codebase that also has to wait for all the major libraries to migrate first, that time frame can quickly shrink to 1-2 years, which is very little.
  - PeterisP 7y ago
    You're waiting for other people to do stuff, and for many of them 1-2 years is the timeframe when they are likely to start working on it. From that perspective 1-2 years is not "too short", it's the "we intentionally chose this as the optimal time". That doesn't really depend on when the deadline is; if you postpone the deadline, then they postpone the migration - as pretty much every library did back in 2014 when the deadline was postponed by 5(!) years. Beggars can't be choosers; if your company wants or needs major libraries to have migrated 4-5 years before the deadline, then your company has to participate in making that migration happen. Or accept that it's going to be done later than you'd like, because the needs and motivation of these library maintainers are quite different from the motivation of Python core maintainers.
    - braythwayt 7y ago
      This x 1000. “The free libraries we chose to depend upon haven’t migrated.” Do you have programmers? “Of course.” Put them to work. “We have other priorities.” Well then. Your choice, your outcome.
      - marcus_holmes 7y ago
        This attitude is ridiculous. I'm supposed to go and tell all the various projects that I depend on that they have to change their upgrade timescales to suit mine? Even if I had enough time to help them all meet that kind of timescale, why would they agree to fit their changes into my required deadline? Maintainers are under a lot of pressure. Having users come along and say "we'll add 50 developers to your project if you agree to ship v3 compliance by next month" is not reducing that pressure, it's adding to it. More programmers != better results or faster delivery. Your solution is just going to create more problems.
        hobofan 7y ago
        You shouldn't take "Do you have programmers?" too literally. Programmers ~= Resources ~= Money => If you want your dependencies to be upgraded in a reasonable time frame, try to contribute to financing the maintainers (or support them in a manner _they_ find suitable).
        ilikehurdles 7y ago
        You fork the library. You fix the incompatibility issues. You issue PRs back to the mainline to help them adopt the same fixes. At some point in the future you can switch back to the main repo if they've migrated, or you can consider that library abandoned and continue to maintain your own or find an alternate. At no point do you have to wait on anyone else, you choose to.
        Kaiyou 7y ago
        You can do that, but then they won't accept your solution, so you just spend time developing a parallel system that you need to support yourself until the end of time. Been there, done that.
  - SiempreViernes 7y ago
    The time frame is 12 years though, since the sunset was originally announced in 2008.
    - hobofan 7y ago
      A lot of libraries refused to migrate before Python 3.5(?) came out which was ~4 years ago. IIRC earlier Python 3 versions had performance regressions compared to Python 2.
      - adamc 7y ago
        This. For most organizations, the effective window has only been 2-3 years. Personally, I would guess that many organizations will be running in Python 2 for at least parts of their codebase come 2020.
- wwright 7y ago
  If the only way your organization can prioritize this is either “drop everything and update” or “completely ignore and do no work to prepare,” then it sounds like Python versioning is not your biggest problem.
  - shawxe 7y ago
    Unfortunately, I think this type of thing actually is the case for many organizations. Trying to explain the business case for paying off technical debt to a non-technical person can be very difficult when "right now everything works."
    - cogman10 7y ago
      I've had to fight developers over this. A lot of devs like to not worry about new things.
    - wwright 7y ago
      I can really understand that… but I believe that such organizations will experience significantly more problems than just Python upgrades. (I work for one.)
  - marcus_holmes 7y ago
    I get this, though: porting code affects all parts of the code base, so it generates git conflicts all the time. It's way more of a pain to do than routine feature development or refactors. It gets difficult to have part of the team work on features while another group works on the port to a new version, because that generates a ton of conflicts. It's easier to get the entire team working on the port. I had to manage a mature codebase upgrading Ruby versions, and it was painful. And that is fairly mild by comparison; not the big jump from Python 2 to 3.
jedberg 7y ago
> Based on your timeline, a four year gap from "not yet ready to migrate" to "we won't fix security vulnerabilities" is very short. Is it though? Especially since as late as 2014, everyone was under the assumption that in 2015 security support would end. We were already trying to migrate long before that. The five year extension seems pretty reasonable to me.
Ensorceled 7y ago
In 2014, things were not quite ready so they extended it 6 more years. If you were upset by this you really need to get out of software development.
shakna 7y ago
Python 2's EOL was first announced in 2008, it was extended in 2014. That's more than a decade of forewarning that this was coming down the line. A decade of Python2 receiving security fixes. Were I a commercial customer, and had been told to switch to the new version ten years ago, then it's on me if I still have started the migration yet.
- mantap 7y ago
  You couldn't switch to Python 3 until the middle part of this decade unless the stars aligned with your dependencies, the library support wasn't there. And the first releases of Python 3 were glorified betas, the first "usable" version of Python 3 is often considered to be version 3.3 released in 2012.
  - ensignavenger 7y ago
    But you could easily write Python 3 compatible code so that upgrading once your dependacies were ready was easy. You also could have contributed to your dependancies to help them become Python 3 compatible.
    - mehrdadn 7y ago
      > But you could easily write Python 3 compatible code so that upgrading once your dependacies were ready was easy. This sounds a bit like telling someone, oh, you could've easily started driving an EV, so that once charging stations were actually out there, you'd have been ready...
      - ericvsmith 7y ago
        > This sounds a bit like telling someone, oh, you could've easily started driving an EV, so that once charging stations were actually out there, you'd have been ready... While car analogies are notoriously bad, it's much more like "I'm going to buy a plug-in hybrid and use gasoline until charging stations are widely available". You can write code that works in Python 2 that takes zero effort to run in Python 3. I (and many others) have been doing this for years. Just look at the number of packages on PyPI that run, unmodified, on 2 and 3. [Edit: gas -> gasoline]
MR4D 7y ago
It was longer than Apple’s move to 64 bit apps on the iPhone. Actually, depending on what action you pin dates to, it was twice as long. One other thing - you can’t run non-64 bit apps anymore. You can still run Python 2.
- Wowfunhappy 7y ago
  That's a pretty low bar. I still think that move by Apple was pretty terrible. Especially given that it's 100% impossible to downgrade iOS (your last point).
  - scarface74 7y ago
    And it’s entirely impossible to run 32 bit apps on newer Apple ARM chips. There is always a cost to keeping old APIs or in Apple’s case, old silicon.
- maccard 7y ago
  It's actually longer than android has been alive...
appleflaxen 7y ago
But it's not commercial, and you had four years of guidance. I feel like this the python community has been the epitome of class regarding communication during a transition.
logifail 7y ago
Windows 10 Enterprise LTSB 2015 (the original long term support version of Windows 10 Enterprise) doesn't support installing .Net 4.7 at all. There are an increasing number of applications which require .Net 4.7, we found one early this year. Promising "10 years of support" for a product is great, but if/when other vendors decide to undercut this, you can still be SoL :(
hiccuphippo 7y ago
I'm pretty sure there will be more than one commercial offer for Python2 support in the future.

PeterisP 7y ago

The thing is, a four year gap is very large from the perspective of "should we drop everything else and prioritize porting our library to python3 right now". If the deadline wasn't 2020 but 2024, then you wouldn't get more time, simply we'd be at "not yet ready to migrate" state right now, as major libraries would not have switched yet.

hobofan 7y ago
> porting our library Library, as is most open source libraries out there, sure. For a big company-internal Python codebase that also has to wait for all the major libraries to migrate first, that time frame can quickly shrink to 1-2 years, which is very little.
- PeterisP 7y ago
  You're waiting for other people to do stuff, and for many of them 1-2 years is the timeframe when they are likely to start working on it. From that perspective 1-2 years is not "too short", it's the "we intentionally chose this as the optimal time". That doesn't really depend on when the deadline is; if you postpone the deadline, then they postpone the migration - as pretty much every library did back in 2014 when the deadline was postponed by 5(!) years. Beggars can't be choosers; if your company wants or needs major libraries to have migrated 4-5 years before the deadline, then your company has to participate in making that migration happen. Or accept that it's going to be done later than you'd like, because the needs and motivation of these library maintainers are quite different from the motivation of Python core maintainers.
  - braythwayt 7y ago
    This x 1000. “The free libraries we chose to depend upon haven’t migrated.” Do you have programmers? “Of course.” Put them to work. “We have other priorities.” Well then. Your choice, your outcome.
    - marcus_holmes 7y ago
      This attitude is ridiculous. I'm supposed to go and tell all the various projects that I depend on that they have to change their upgrade timescales to suit mine? Even if I had enough time to help them all meet that kind of timescale, why would they agree to fit their changes into my required deadline? Maintainers are under a lot of pressure. Having users come along and say "we'll add 50 developers to your project if you agree to ship v3 compliance by next month" is not reducing that pressure, it's adding to it. More programmers != better results or faster delivery. Your solution is just going to create more problems.
      - hobofan 7y ago
        You shouldn't take "Do you have programmers?" too literally. Programmers ~= Resources ~= Money => If you want your dependencies to be upgraded in a reasonable time frame, try to contribute to financing the maintainers (or support them in a manner _they_ find suitable).
      - ilikehurdles 7y ago
        You fork the library. You fix the incompatibility issues. You issue PRs back to the mainline to help them adopt the same fixes. At some point in the future you can switch back to the main repo if they've migrated, or you can consider that library abandoned and continue to maintain your own or find an alternate. At no point do you have to wait on anyone else, you choose to.
        Kaiyou 7y ago
        You can do that, but then they won't accept your solution, so you just spend time developing a parallel system that you need to support yourself until the end of time. Been there, done that.
- SiempreViernes 7y ago
  The time frame is 12 years though, since the sunset was originally announced in 2008.
  - hobofan 7y ago
    A lot of libraries refused to migrate before Python 3.5(?) came out which was ~4 years ago. IIRC earlier Python 3 versions had performance regressions compared to Python 2.
    - adamc 7y ago
      This. For most organizations, the effective window has only been 2-3 years. Personally, I would guess that many organizations will be running in Python 2 for at least parts of their codebase come 2020.
wwright 7y ago
If the only way your organization can prioritize this is either “drop everything and update” or “completely ignore and do no work to prepare,” then it sounds like Python versioning is not your biggest problem.
- shawxe 7y ago
  Unfortunately, I think this type of thing actually is the case for many organizations. Trying to explain the business case for paying off technical debt to a non-technical person can be very difficult when "right now everything works."
  - cogman10 7y ago
    I've had to fight developers over this. A lot of devs like to not worry about new things.
  - wwright 7y ago
    I can really understand that… but I believe that such organizations will experience significantly more problems than just Python upgrades. (I work for one.)
- marcus_holmes 7y ago
  I get this, though: porting code affects all parts of the code base, so it generates git conflicts all the time. It's way more of a pain to do than routine feature development or refactors. It gets difficult to have part of the team work on features while another group works on the port to a new version, because that generates a ton of conflicts. It's easier to get the entire team working on the port. I had to manage a mature codebase upgrading Ruby versions, and it was painful. And that is fairly mild by comparison; not the big jump from Python 2 to 3.

jedberg 7y ago

> Based on your timeline, a four year gap from "not yet ready to migrate" to "we won't fix security vulnerabilities" is very short. Is it though? Especially since as late as 2014, everyone was under the assumption that in 2015 security support would end. We were already trying to migrate long before that. The five year extension seems pretty reasonable to me.

Ensorceled 7y ago

In 2014, things were not quite ready so they extended it 6 more years. If you were upset by this you really need to get out of software development.

shakna 7y ago

Python 2's EOL was first announced in 2008, it was extended in 2014. That's more than a decade of forewarning that this was coming down the line. A decade of Python2 receiving security fixes. Were I a commercial customer, and had been told to switch to the new version ten years ago, then it's on me if I still have started the migration yet.

mantap 7y ago
You couldn't switch to Python 3 until the middle part of this decade unless the stars aligned with your dependencies, the library support wasn't there. And the first releases of Python 3 were glorified betas, the first "usable" version of Python 3 is often considered to be version 3.3 released in 2012.
- ensignavenger 7y ago
  But you could easily write Python 3 compatible code so that upgrading once your dependacies were ready was easy. You also could have contributed to your dependancies to help them become Python 3 compatible.
  - mehrdadn 7y ago
    > But you could easily write Python 3 compatible code so that upgrading once your dependacies were ready was easy. This sounds a bit like telling someone, oh, you could've easily started driving an EV, so that once charging stations were actually out there, you'd have been ready...
    - ericvsmith 7y ago
      > This sounds a bit like telling someone, oh, you could've easily started driving an EV, so that once charging stations were actually out there, you'd have been ready... While car analogies are notoriously bad, it's much more like "I'm going to buy a plug-in hybrid and use gasoline until charging stations are widely available". You can write code that works in Python 2 that takes zero effort to run in Python 3. I (and many others) have been doing this for years. Just look at the number of packages on PyPI that run, unmodified, on 2 and 3. [Edit: gas -> gasoline]

MR4D 7y ago

It was longer than Apple’s move to 64 bit apps on the iPhone. Actually, depending on what action you pin dates to, it was twice as long. One other thing - you can’t run non-64 bit apps anymore. You can still run Python 2.

Wowfunhappy 7y ago
That's a pretty low bar. I still think that move by Apple was pretty terrible. Especially given that it's 100% impossible to downgrade iOS (your last point).
- scarface74 7y ago
  And it’s entirely impossible to run 32 bit apps on newer Apple ARM chips. There is always a cost to keeping old APIs or in Apple’s case, old silicon.
maccard 7y ago
It's actually longer than android has been alive...

appleflaxen 7y ago

But it's not commercial, and you had four years of guidance. I feel like this the python community has been the epitome of class regarding communication during a transition.

logifail 7y ago

Windows 10 Enterprise LTSB 2015 (the original long term support version of Windows 10 Enterprise) doesn't support installing .Net 4.7 at all. There are an increasing number of applications which require .Net 4.7, we found one early this year. Promising "10 years of support" for a product is great, but if/when other vendors decide to undercut this, you can still be SoL :(

hiccuphippo 7y ago

I'm pretty sure there will be more than one commercial offer for Python2 support in the future.