On Sat, Nov 4, 2017 at 11:00 PM, Wolfgang <tds...@mailbox.org> wrote: > > > On 04.11.2017 12:35, Chris Angelico wrote: >> >> On Sat, Nov 4, 2017 at 10:25 PM, <tds...@mailbox.org> wrote: >>> >>> I suggest to change this to increment the major version for every new >>> release >>> of the 1,5 year cycle. >>> And allow new Python standard library backward compatible changes for >>> every >>> minor release cycle every 6 months. >> >> >> The usual implication of a major version bump is that there is >> significant incompatibility. That's something that should happen >> roughly once a decade, not every couple of years. Massive -1.0 from me >> on this. >> > > Yes that implication is a possible risk. I will add it to the section > if needed. > > As noted by Guido a ground breaking change as it happened from version 2 to > 3 should never happen in Python land again and a possible version 4 will > simply be after 3.9. > Other languages increment their major version already faster and track > the language standard simply with the major version. > > The major version should be incremented for a ground breaking change > but an increment requires not a ground breaking change to do this. > > For me even adding new keywords to a language is a major change. > (Such as async and await) > Or changes in the C API. > And talking about language standard version 4 is simpler than a > more complicated scheme of major.minor. > Also other implementations such as pypy can use this first version > number in their name to show compatibility. > (pypy4 compatible to Python ) > > I think if the changes happens it will take some time for people to > adjust but then life will be simpler. :-) > > Thank you for your feedback.
If I write code for Python 3.4 and try to run it on Python 3.7, there is a small probability that it will break (eg if it tries to use "await" as a function name - I had a program like that, and once the new keywords were pushed through, I renamed it to "wait" to ensure compatibility). But it's a fairly small chance, and it's usually pretty easy to write code that's compatible with several minor versions (by targeting the oldest and then testing on the newer ones). With major version changes, it's much harder to be compatible with both, and you often end up with compatibility shims (eg "try: input = raw_input; except NameError: pass"). This applies to code, to documentation, to answers on Stack Overflow, to blogs, and to everything else that discusses Python in any way. At work, we have to use certain JavaScript packages that have had, I kid you not, more than one major version bump per year since initial release. One time we only discovered an issue after a student installed the latest version of something, and the setup instructions didn't work. Oh, great, version 10 breaks things compared to version 9. I do NOT enjoy dealing with that kind of incompatibility, and permitting it every 1.5 years is a bad thing. And if compatibility is to be guaranteed, why bump the major version number? That's the whole point of the three-part version. ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
