On Fri, Oct 18, 2019 at 3:18 AM Victor Stinner <vstin...@python.org> wrote:
> 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. The proposal seems to add another dimension to the complexity the language is already facing. So instead of trying to keep up with different versions (and how they affect the core functionality or stdlib, or 3rd party libs), it adds another degree of freedom to area, so it is no longer identified by the version it supports only, but also by (possibly) a list of compatibility versions it also supports and on which functionality subset. Determining the target version for the project in this environment will become a serious task for an optimizer: If someone maintains a project on version A and version B introduces some new features and breaks some other things he may: 1) either backport the relevant new things from B to his project, 2) migrate the project from A to B 3) leave it be Whatever he will choose would depend on the importance and effort required and I would consider this to be a "standard" approach and I do not see anything wrong with that. Now, let's say B introduces some new features and breaks some things and provides B(a) compatibility mode for 'a' functionality. Now the project maintainer has new options (apart from the previous ones): 4) Convince Python devs to define 'a' as such that B(a) will cover his project "legacy" code, so he would be able to switch to B(a) without doing anything. 5) If the lobbying does not succeed he still may be able to use B(a) and just migrate from A to B(a) (assuming that A->B(a) is less effort than full A->B). In both last cases the project will find itself in a "compatibilty version" in between, i.e. neither runs on pure A, nor on pure B. Now imagine the project will use 3rd party lib, which may run on A, or B, but would not support B(a) (i.e. mixing the different features from both versions A and B will break the lib). Maybe he will be able to run the lib in a restricted "pure A" version mode (because the project will not need the other non-compatible functionality), or in a restricted "pure B" (for the same reason), or he may try to convince the 3rd party lib dev to support also B(a). Would I venture into B(a) land with my project? Definitely not. But I am writing "small stuff" (experimental code, which usually depends on 3rd party code as well). I would be interested to know, from people who do the "serious stuff", business logic, production code, how they feel about it and how they plan to do lobbying at the core-devs to get the right B(a). Richard
_______________________________________________ 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/QHUY74W2LPA2VIFPTZYIF6QMUPAC6644/ Code of Conduct: http://python.org/psf/codeofconduct/
