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.hettinger@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-leave@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/V2EDFDJG...
-- Christian Tismer :^) tismer@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