placeholder VS pip

This guy wasn't maintaining Python, he as creating a new version incompatible with either Python 2.7 or Python 3.

Red Hat and other large companies have maintained Python for years after 2.7 died (EOL date was January 1st, 2020). IBM/Red Hat offer Python 2.7 including security fixes and bug fixes until 2024 (https://access.redhat.com/solutions/4455511).

Had he just provided patches to Python 2.7, nobody would've batted an eye. Instead, they created an alternative language that was completely different (https://web.archive.org/web/20161210161837/https://www.nafta...).

Founders and core devs indicated that the name was the only problem (https://github.com/naftaliharris/tauthon/issues/47#issuecomm...) and that even things like the header file names could continue to be named Python because of API compatibility.

You can fork any open source project you like, but you still need to stick follow trademark law. You can't just release Linux 2.7 because you disagree with breaking changes in 3.0 either, but you're free to take the Linux code and release Twonux if you really care.

If that doesn't work for some reason, there's this project which claims to be an "active" fork of Python 2, but it also has a lot of backports and additions so I worry a bit about backward compatibility and stability: https://github.com/naftaliharris/tauthon You would have to build this from source as well.

Without developers of the compilers all others groups are pretty much irrelevant. There were lots of people who were telling that Python3 is abomination and some even attempted to fork it but fork haven't caught enough interest thus Python2 is, for all intends and purposes, dead.

Python developers noticed that people are not in any hurry to switch but instead of trying to understand “why” they have drawn the line in the sand and spent their efforts trying to kill unofficial attempts to create a fork.

WinAmp 2 (1998) was widely liked. WinAmp 3 (2002) was considered bloated, and flopped.

So Nullsoft followed it up with WinAmp 5 – because 2+3=5 – in 2003, which was very broadly the codebase of WinAmp 2 (small and lean) plus the skin support from WinAmp 3 (the only part people liked).

This won people back, and WinAmp is still around and got an update this year, 20 years on.

I think it's too late for there to be a Python 5, but I did read a blog post long ago – which I can't find again, or I'd link to it – which proposed a similar compromise fix to Python, in considerable technical detail.

I am with @blagie on this: the Python world handled the 2→3 transition spectacularly badly. V3 didn't deliver enough, and strong-arming people by just end-of-lifing Python 2 and expecting the world to move on was foolhardy and short-sighted.

(And I don't even use the language myself. I'm just observing.)

It's a real shame Tauthon didn't get more traction and support.

https://github.com/naftaliharris/tauthon

If it had got enough support and continued, maybe the Python maintainers would have learned something, but I've not seen any sign that they have.

This is nothing new. For comparison, Perl 6 went so badly that Perl 5 now looks likely to continue as Perl 7:

https://www.perl.com/article/announcing-perl-7/

And PHP 6 didn't really happen -- AFAICT as a total outsider, Unicode support proved too hard and it was never released; the community backported the important bits to PHP 5, and then a new PHP 7, more modest in scope, developed from PHP 5.

The Python world could have done the same, and Tauthon was an effort in that direction.

It's too late now. I suspect that, just as Perl has lost a massive amount of interest and use, partly from the nearly-two-decade-long effort to release Perl 5, Python has done the same -- sabotaged its own community with this high-handed "your leaders know best" approach.

I just can't see a major fork happening (see: Tauthon, a fork of 2.7 to keep it alive, but no updates in a year or so).

If you want forks there are forks. Off the top of my head, Redhat is supporting Python 2 for several more years and there's a project called Tauthon [1] that is "Python 2.8" in spirit. I'm sure there's more efforts I'm not aware of.

[1] https://github.com/naftaliharris/tauthon

Whenever you are working on a Python project that has external dependencies installed with pip, it is strongly recommended to first create a virtual environment.

Unfortunately that feature is easy to break: https://github.com/pypa/pip/issues/9644

I think I did my part https://github.com/pypa/pip/issues/6409

$ sudo pip install y$ sudo pip install yaml WARNING: pip is being invoked by an old script wrapper. This will fail in a future version of pip. Please see https://github.com/pypa/pip/issues/5599 for advice on fixing the underlying issue. To avoid this problem you can invoke Python with '-m pip' instead of running pip directly. ERROR: Could not find a version that satisfies the requirement yaml (from versions: none) ERROR: No matching distribution found for yaml

What are you implying will happen?

Using the build-in tools, you can save the exact versions of dependencies (i.e. a lock file) using "pip freeze >dependencies.txt". This should give you the exact same set of packages in two years' time.

If you want to be even more sure, you can also store hashes in the lock file. This has to be generated by a separate tools at the moment [1][2] but can be consumed by the built-in tools [3], so "pip install -r requirements.txt" is still all you need in two years' time.

[1] https://github.com/pypa/pip/issues/4732

[2] https://pip-tools.readthedocs.io/en/latest/#using-hashes

[3] https://pip.pypa.io/en/stable/topics/secure-installs/#hash-c...

Here’s the issue, https://github.com/pypa/pip/issues/11664. I think the idea would be to have some file/json description of environment that could be passed to pip to allow it to fully cross compile. They are open to supporting it just needs contributor to be found to implement it and go through review/discussion.

To be fair the only alternative is fixing Python, and even then you still would have to wait a good 5 years at least for all the old Python versions to dwindle.

It doesn't look like the fixing effort is progressing very quickly: https://github.com/pypa/pip/issues/8606

To their credit, at least they didn't close it "works as intended" which I imagine a lot of projects would.

Another good benchmark to trying to resolve apache-airflow[all]==1.10.13 using the state of PyPi on 2020-12-02, I give instructions here on how to reproduce that workflow: https://github.com/pypa/pip/issues/11836. Including a benchmark how how many extra packages your resolver should visit.