Hey friends, This is IMHO a great idea. If a package claims to be Python 3.8 compatible, then it has to be correct concerning invalid escapes.
A new pip version could perhaps even refuse packages with such literals when it claims to be supporting Python 3.8 . But how can it actually happen that a pre-3.8 package gets installed when you install Python 3.8? Does pip allow installation without a section that defines the allowed versions? Ok, maybe packages are claimed for Python 3.8 and not further checked. But let's assume the third-party things that Raymond sees do _not_ come from pip, but elsewhere. Pre-existing stuff that is somehow copied into the newer Python version? Sure, quite possible! But then it is quite likely that those third-party things still have their creation date from pre-3.8 time. What about the simple heuristic that a Python module with a creation date earlier than xxx does simply not issue the annoying warning? Maybe that already cures the disease in enough cases? just a wild idea - \leave \old \code \untouched -- ciao - \Chris On 06.08.19 18:59, Neil Schemenauer wrote: > > Making it an error so soon would be mistake, IMHO. That will break > currently working code for small benefit. When Python was a young > language with a few thousand users, it was easier to make these > kinds of changes. Now, we should be much more conservative and give > people a long time and a lot of warning. Ideally, we should provide > tools to fix code if possible. > > Could PyPI and pip gain the ability to warn and even fix these > issues? Having a warning from pip at install time could be better > than a warning at import time. If linting was built into PyPI, we > could even do a census to see how many packages would be affected by > turning it into an error. > > On 2019-08-05, raymond.hettin...@gmail.com wrote: >> P.S. In the world of C compilers, I suspect that if the relatively >> new compiler warnings were treated as errors, the breakage would >> be widespread. Presumably that's why they haven't gone down this >> road. > > The comparision with C compilers is relevant. C and C++ represent a > fairly extreme position on not breaking working code. E.g. K & R > style functional declarations were supported for decades. I don't > think we need to go quite that far but also one or two releases is > not enough time. > > Regards, > > Neil > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/V2EDFDJGXRIDMKJU3FKIWC2NDLMUZA2Y/ > -- Christian Tismer :^) tis...@stackless.com Software Consulting : http://www.stackless.com/ Karl-Liebknecht-Str. 121 : https://github.com/PySide 14482 Potsdam : GPG key -> 0xFB7BEE0E phone +49 173 24 18 776 fax +49 (30) 700143-0023 _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XVJCYXDZ7VPMMCTP2BPNAJ3OO7S4II4V/
