If the __version__ variable is used, I suggest to start with a deprecation period using a module __getattr__(): emit DeprecationWarning, and only remove these variables in 2 Python releases (PEP 387).
sys.version or sys.version_info can be used instead of argparse.__version__, no? Victor Le mer. 14 oct. 2020 à 22:30, Batuhan Taskaya <isidenti...@gmail.com> a écrit : > > I've indexed a vast majority of the files from top 4K pypi packages to this > system, and here are the results about __version__ usage on argparse, cgi, > csv, decimal, imaplib, ipaddress, optparse, pickle, platform, re, smtpd, > socketserver, tabnanny (result of an quick grep) > > > rawdata/clean/argparse/setup.py > > argparse.__version__ > > rawdata/pypi/junitparser-1.4.1/bin/junitparser > > argparse.__version__ > > rawdata/pypi/interpret_community-0.15.1/interpret_community/mlflow/mlflow.py > > pickle.__version__ > > The pickle in the last example looks like a result of import cloudpickle as > pickle, so we are safe to eliminate that. > > Here is the query if you want to try by yourself on different parameters: > https://search.tree.science/?query=Attribute%28Name%28%27argparse%27%7C%27cgi%27%7C%27csv%27%7C%27decimal%27%7C%27imaplib%27%7C%27ipaddress%27%7C%27optparse%27%7C%27platform%27%7C%27pickle%27%7C%27re%27%7C%27smtpd%27%7C%27socketserver%27%7C%27tabnanny%27%29%2C+%22__version__%22%29 > On 14.10.2020 21:23, Neil Schemenauer wrote: > > On 2020-10-14, Serhiy Storchaka wrote: > > I propose to remove __version__ in all stdlib modules. Are there any > exceptions? > > I agree that these kinds of meta attributes are not useful and it > would be nice to clean them up. However, IMHO, maybe the cleanup is > not worth breaking Python programs. We could remove them from the > documentation, add comments (or deprecation warnings) telling people > not to use them. > > I think it would be okay to remove them if we could show that the > top N PyPI packages don't use these attributes or at least very few > of them do. As someone who regularly tests alpha releases, I've > found it quite painful to do since nearly every release is breaking > 3rd party packages that my code depends on. I feel we should try > hard to avoid breaking things unless there is a strong reason and > there is no easy way to provide backwards compatibility. > _______________________________________________ > 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/MI2SLQCZIKBRFX7HCUB7G4B64MTZ6XVC/ > Code of Conduct: http://python.org/psf/codeofconduct/ > > _______________________________________________ > 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/MSQTTUZOW6KSECSZE5XH65LANGII2P5F/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ 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/WTTUGC7RQZLV6XQPVQAV4RVELNLAIATM/ Code of Conduct: http://python.org/psf/codeofconduct/
