On 2019-10-17 18:02, Victor Stinner wrote:
Hi,
I propose the following PEP to add
sys.set_python_compat_version(version) to introduce a partial
compatibility with Python 3.8 in the next Python 3.9 version.
I also propose this PEP in a pull request:
https://github.com/python/peps/pull/1209
(Please avoid using the temporary PEP number until this PR is merged:
officially, the PEP has no number yet.)
If possible, please try to read the whole PEP before replying. I would
prefer to avoid knee-jerk reactions :-) The backward compatibility is
complex topic where things are not black or white: it's more a
grayscale.
IMHO with the incoming end of Python 2 support, it's the right time to
propose this PEP!
I read the PEP, but I find it a bit difficult to understand what it's
actually proposing.
It seems like you are proposing that there be this function
set_python_compat_version which will effectively act as a global flag
affecting various functionality in the standard library, namely by
making it work as it did in a past version of Python. Is that the basic
idea?
My main point of confusion is that I don't see an explicit list of what
functionality will be supported by this flag. In the abstract it says
"Modify a few functions of the standard library to implement a partial
compatibility". What precisely are those functions? Because of this
omission, I can't tell if this PEP is actually proposing a specific set
of accommodations to backwards compatibility, or just proposing a
mechanism for handling such accommodations.
If the PEP is proposing that existing stdlib functions be modified to
actually check the compatibility version and give different behavior
accordingly, I think there needs to be an exhaustive list of which
functions those will be and what exactly the flag will do.
If it's just proposing a mechanism, without necessarily proposing that
any actual changes be made to use that mechanism, okay, but I'm somewhat
skeptical that that will get much traction,
Actually I'm somewhat skeptical it'll get much traction anyway. The
overall issue seems to be more a human issue of governance and
priorities. The problem is, even supposing this mechanism is in place,
who is going to enforce it to ensure that any time a
backwards-incompatible change is made, it is accompanied by work to make
the changes "undoable" via this "compat version" mechanism? Having a
function called set_python_compat_version is no good unless, going
forward, every backwards-incompatible change is blockable this way,
because otherwise someone who relies on old behavior that isn't
"compatibilized" will still be unable to upgrade in the same way you
describe in your rationale.
In other words, it doesn't matter if we have set_python_compat_version,
what matters is how fully it actually covers the backwards compatible
changes. It seems like enforcing a policy of "every backwards
compatible change must be compatabilizable in this way" is more a matter
for the dev team's internal guidelines (akin to "you must provide unit
tests") than for a PEP.
The part that confuses me the most is this:
"Backward compatibility code will be dropped at each Python release, on
a case by case basis. Each compatibility function can be supported for a
different number of Python releases depending on its maintenance cost
and the estimated risk (number of broken projects) if it's removed."
Isn't that sort of already what deprecation schedules and the like are
supposed to accomplish? It seems like this paragraph totally undercuts
the whole point of the proposal. Right now maybe we have a situation
where if I'm on Python 4.8 and the newest version is 4.9, I could be
bitten by backwards incompatibility. With this change, I could be on
Python 4.8 and maybe the newest is 4.12 and I'm hanging on by setting
compat mode. But if the specific old features I haven't yet phased out
are the ones dropped from compat mode in 4.13, then the whole mechanism
is useless to me. So it just delays the incompatibility barrier a few
versions, which is what deprecation schedules are already supposed to
do. If backwards compatibility is itself going to be
backwards-incompatibly removed, how is it better to use this system than
to just give every breaking change a deprecation schedule that will
phase it out over the same amount of time?
I'm leaving aside some of the even hairier corner cases, such as the
situation mentioned in the PEP where behavior could depend on import
order because the behavior of compatibilized functions may change on the
fly if multiple calls to set_compat_version occur. That sounds like a
recipe for disaster, and suggests to me that the whole issue is better
handled with some kind of external declarative system (akin to pip or
conda dependency tracking) rather than a Python-internal system which is
subject to the vagaries of execution order.
As I said, I may be misunderstanding the PEP, but either way I think it
could benefit from some editing, because the way it is structured right
now is (to me) quite confusing. It just starts off by saying it will
"add sys.set_python_compat_version(version) to enable partial
compatibility" and then claims it will "modify a few functions of the
standard library" to implement this, but I can't see anywhere that it
says what those functions are, and because of that I'm no longer even
sure what it means by "enable partial incompatibility". I think the
"specification" section needs to be a lot more, well, specific.
Also, just as a minor point, I don't think it is a good idea to name
the function "set_python_compat_version" if it's not actually setting
the version --- which it isn't because according to the PEP the actual
compat version will be set to the minimum of any versions passed if this
function is called multiple times. That's not what "setting" the
version means to me; if I set something to 2 and then I set it to 3, I
expect its value to then be 3, but with this it would still be 2. A
better choice would be a name like "require_compatibility_with", which
is more compatible (har har) with the idea that multiple calls coalesce
into their minimum. Likewise set_python_min_compat_version might be
better as "prohibit_compatibility_with" or something.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/TY3CR6372VUYVWW2RIZRWI5UMFBTVN3N/
Code of Conduct: http://python.org/psf/codeofconduct/
