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.
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.
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.
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."
I can really understand that… but I believe that such organizations will experience significantly more problems than just Python upgrades. (I work for one.)
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.
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.
This is dumb. You're blaming people who probably don't get to call the shots. The managers who do have the ability to make different decisions are, themselves, often under the gun to meet other commitments.
Sure, they will have to cope. One of the ways people cope is by accepting security risks and continuing to run with old versions. Another is to decide that Python isn't for them, and move resources toward better platforms with commercial support for older code.
The fact is, that until a few years ago there were too many libraries that were not compatible for most organizations to make the switch. So, effectively the window for those organizations has only been a few years.
There is also the third choice - you don't migrate and keep doing your job (developing features) on the legacy code base. Things like certificates will have ad-hoc solutions pushed whether you like it or not, and the language will keep trundling along.
If there wind up being major security issues, there will be little choice but for someone to take up the mantle and fix them. Because companies aren't going to switch, and when you've got a botnet ravaging the internet they can't flip a switch and do a big-bang rewrite, someone will have to push out a patch for them.
This isn't the end of Python 2, it's just the Python team washing their hands of it. Ask PHP or Cobol users how their attempts to kill legacy codebases worked out for them.
This whole endeavor was complete folly from the Python foundation to begin with. A big-bang rewrite because they didn't like the syntax, and they didn't even fix the GIL while they were at it.
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.
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.
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.
If there is significant demand for solving the problem your fork solves, others will migrate to it. This is made harder when the main solution gets to squeak along for 10 extra years on a version of the language that should no longer get first-party support. Of course there is going to be less demand for that Py3 solution when there is no immediate consequence for continuing on Py2. Killing security update support for 2 will boost the demand for libraries using 3, and make it more likely that your fork gets merged or becomes the defacto standard.
The Python 2->3 window is an example of where being too nice to too many users harms the project. Once Python 2 is dead, people will choose between being the sole maintainer of a Python 3 fork of some Python 2 library versus a being a sole maintainer of their entire Python 2 stack from the language layer on up.
How are they supposed to migrate if I can't openly host my solution because it was developed on company time? Merging back into the original project is one thing, but making your solution available some other way is a whole other story.
This is the reality of having lots of open source dependencies. Important changes/bugs may exist, and the maintainers are under no obligation to fix them to suit your business needs. If you want them fixed, you contribute to the code base (or fork it) and fix it.
Still better than my last programming job where the vendor of a vital piece of HW had provided a C++ API (also vital), but refused to provide dlls that would work in anything newer than VS2010. At least with open source you can do something about it.
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).
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.
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.