On 30 July 2017 at 07:57, Björn Persson <Bjorn@rombobjörn.se> wrote: > Mathieu Bridon <bochecha@xxxxxxxxxxx> wrote: >> To be honest, given how much energy is spent on this migration for a >> very low gain, it makes me feel like having an unversioned "python" >> (whether as package or executable names) was a mistake we should let >> disappear with Python 2. > > I agree. > > From an emotional point of view I fully understand the Python folks' > desire to have "Python" mean Python 3, and that's fine in marketing > contexts such as websites. While I'm a CPython core dev in addition to being a RHEL developer, it's mainly the latter role that leads me to consider the status quo in Fedora as being rather problematic :) > But filenames and package names are technical > identifiers. They must be chosen so that they'll fulfil their functions, > and with consideration for forward and backward compatibility. Right. Unfortunately, the folks saying "just use /usr/bin/python3 in your shebang lines" are choosing to ignore systems that don't have, and *aren't going to get* a Python 3 installation. Even if Red Hat were to start making a native Python 3 stack available, there would still be an awful lot of EL6 and EL7 systems around where that stack isn't going to be installed. So that's effectively a hard design constraint for me: folks targeting EL6 and EL7 *are* going to have to use "/usr/bin/python" in their shebang lines (since they can't even assume "/usr/bin/python2" will be present, let alone "/usr/bin/python3"), so I have to assume that "just tell Red Hat's customers to change all their Python shebang lines to require Python 3" isn't one of the design options I have available to me. That means the only degrees of freedom I/we potentially have are related to what "/usr/bin/python" means in Fedora. The status quo is that by default such scripts simply break, and if you want them to work, you have to install the full Python 2.7 stack. If you want to do anything else, you have to resort to creating symlinks manually, and as soon as you do, your system is in an unsupported configuration, so if it breaks, any bugs you file are just going to be closed as "not a bug". Accordingly, my proposal is that we support *3* admin selectable configurations (probably using the modularity tooling as the config switching mechanism) instead of the current two: 1. Absent (the current default) 2. Python 2.7 (a legacy Python stack gets installed in parallel with the default one) 3. Python 3.x (such scripts are run in the default Python 3 stack) The third option is the new possibility I'm proposing, and it acknowledges that there's an awful lot of Python 2 code that will actually run under Python 3 once you run python-modernize over it to drop the use of ancient idioms (especially if you allow use of the "six" runtime compatibility library). If we introduce the 3rd option via the modularity tooling as a new opt-in behaviour for F27 while retaining the "absent" default indefinitely, then when the upstream end of maintenance for Python 2.7 rolls around in 2020, we won't need to change the default, we'd just look at dropping the entire legacy Python 2.7 stack. > Providing > an unversioned "python" serves only to lure incautious programmers into > using it where they should use a versioned name. My aim is for folks to start thinking of a "/usr/bin/python" shebang as being akin to writing "/bin/sh" instead of "/bin/bash": as the author of the script, by deciding not to explicitly qualify your shebang line you're saying "I'm not writing in either Python 2 *or* Python 3, I'm writing in the hybrid subset of both of them". There aren't many good reasons for a script in a distro package to do that (they should just depend on the stack they want), but there are plenty of good reasons for multi-distro scripts to be written that way. As time goes by, I'd expect the meaning of the unqualified variant to shift slightly such that "/usr/bin/python" is taken to mean "written in the oldest Python dialect that is still actively supported by upstream and/or commercial vendors (or potentially even older than that)" while "/usr/bin/python3" retains its current meaning of "run in the default Python 3 stack" (with the two links thus becoming functionally equivalent for systems that only have one Python stack installed). Cheers, Nick. -- Nick Coghlan | ncoghlan@xxxxxxxxx | Brisbane, Australia _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
