Gregory P. Smith <g...@krypto.org> added the comment:
The problem with a SyntaxWarning is that the wrong people will see it. It gets in the way of users of applications that happen to be written in Python. scenarios: (a) A Python interpreter gets upgraded, and suddenly the _users_ of an application start seeing nasty warnings when they invoke the tool that happens to be implemented in Python. Warnings that they have no power to do anything about. (b) A developer installs the shiny new version of Python with the warning feature, then pip install's all of the dependencies for the application they are working on. Some of those contain "is" problems so they're left in a situation where they either have to figure out how to fix code from N different transitive dependencies libraries that they are not the author of - or not use that Python version to ship their code. Keep in mind that it is common for deps to be pinned to ranges of versions instead of "always the latest" so even when deps fix their code, many people won't see it for a long time. These scenarios are real, this is exactly what happened with the DeprecationWarning added to the old md5.py and sha.py modules. A warning raised at import time isn't even one that can be meaningfully caught in a well structured application. Doing so requires importing the warnings module first thing and setting up warning filters before any other imports. This is ugly boilerplate for anyone to need to resort to. As much as I want us to do something to ameliorate this anti-pattern in code, I don't think a SyntaxWarning is a great way to do it. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue34850> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
