Naming your language interpreters and ecosystem

Last week, Fedora contributors proposed to change the meaning of “python” from “python2” to “python3” starting with Fedora 31. This makes sense in the context of Python 2’s upcoming demise. But some feedback on the mailing list, including mine, wonders why we’re perpetuating it.

Should there also be no “pip”, no “pytest”, no “pylint”, … command? I would say “yes”. Admittedly, it’s avoiding future pain in exchange for some current pain. But we’re already dealing with a disruption, so why enable the same issues when it’s time for Python 4?

This is bigger than Python, though. If you’re following semantic versioning, I argue that you should name your interpreters and any ecosystem executables with the major version name. Unless you’re promising to always maintain backward compatibility (or to just stop working on the project), you’re eventually setting your users up for pain.

What about non-programming languages? This is probably good advice for anything with a client-server model (e.g. databases). Or anything else where the command is separated from other components of the ecosystem. You could extend this to any executable or script that may be called by another. That’s not wrong, but there’s probably a reasonable line to draw somewhere.

Wherever you draw the line, doing it from the beginning makes life easier when the new, incompatible version comes out.