I dont buy this argument at all. Any sufficiently complex Python 2 project does not work with Python 3 without modification, there is _no_ cross-version compatibility.

And if you wanted to try that yourself anyway, changing all .py to .py3 in a directory is one unix command... It could easily have been part of a 2to3 tool

> I dont buy this argument at all. Any sufficiently complex Python 2 project does not work with Python 3 without modification, there is _no_ cross-version compatibility.

I was personally and solely responsible for migrating a >250kLOC project from Python 2 to Python 3, doing so without cross-version compatibility would not have been feasible. We literally picked the earliest P3 version we decided to support based on cross-compatibility features.

The issue is third-party libraries: They need to simultaneously support both versions of Python during the transition period. If you unilaterally migrate to v3, you break lots of existing projects. On the other hand, if you stay v2 only, you‘re holding up your dependent projects’ migration efforts.

I understand the benefit in theory, but in practice, you had two options :

- the codebase had to be modified to work on both versions at the same time

- you had to maintain two versions in different branches for a while

Is there any data to show which options was most often chosen amongst all pypi packages? I suspect that the second option was more popular for the most important packages of the ecosystem

The first option was by far the most popular and was used for years (including pip), only recently packages started dropping python 2 support. I'm not even aware of any packages which went with the second.

They made option 1 possible because people complained about option 2.

six was the #2 package on PyPI.[1] It's a library to help with option 1.

[1] https://python3wos.appspot.com/

> I suspect that the second option was more popular for the most important packages of the ecosystem

You're 100% wrong. The few packages which decided on option 2 early on (e.g. dateutil) ended up having to roll back to option 1 because it was such a pain in the ass, both for the maintainer and for downstream users. The migration only really started happening once 2.7 dropped, projects like Six[0] started appearing, and the community started ignoring 2to3 and building up experience with cross-version projects and idioms (e.g. [1], [2])

[0] whose entire point is to help with option 1

[1] https://eev.ee/blog/2016/07/31/python-faq-how-do-i-port-to-p...

[2] https://python-future.org/compatible_idioms.html

"the codebase had to be modified to work on both versions at the same time"

This. This is the only option.

I can tell you in decades of experience with I don't know how many companies and language, this is ALWAYS the option that is done.