On Fri, Oct 16, 2020 at 3:08 AM Steve Holden <st...@holdenweb.com> wrote:
> Since some code clearly accesses __version__, would it make sense to equip > all stdlib modules with a __version__ property that returned the Python > version, suitably prefixed? > That's another way to go, but I don't think that really provides more accurate information specifically. If we were going to go that way then I would advocate making __version__ a PEP-ified thing to get the whole community to buy in (but I don't know if that's useful to begin with). -Brett > > Kind regards, > Steve > > > On Fri, Oct 16, 2020 at 5:28 AM Karthikeyan <tir.kar...@gmail.com> wrote: > >> On Fri, Oct 16, 2020, 12:45 AM Serhiy Storchaka <storch...@gmail.com> >> wrote: >> >>> 14.10.20 20:56, Brett Cannon пише: >>> > I think if the project is not maintained externally and thus synced >>> into >>> > the stdlib we can drop the attributes. >>> >>> I have found only one exception. decimal.__version__ refers to the >>> version of the external specification which was not changed since 2009. >>> I think it should be kept, although it might be better to use different >>> name for it (like "spec_version"). >>> >>> I do not know about any current projects maintained externally and >>> synced into the stdlib. simplejson and ElementTree are too different now >>> from the stdlib versions. Some features flow in both directions, but >>> selectively on case by case basis, not as full sync. External argparse >>> is outdated now. >>> >> I guess zipp that is maintained externally has code adopted into >> zipfile.ZipPath regularly : https://github.com/jaraco/zipp >> >> __version__ was removed from mock and it broke a package in fedora. The >> PR has a discussion and also links to the bpo to remove __version__ from >> all of stdlib : https://github.com/python/cpython/pull/17977 >> >> I am also in favor of removing since it causes confusion when the package >> is not maintained externally n synced into stdlib. >> >> Thanks >> >> _______________________________________________ >>> 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/MIEMWWC5W2WKV25WTARXACQOIUBUUSLS/ >>> 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/3NY5JIFUP5674Q3FR2DOMLXGBE6D4XJD/ >> 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/JZ4JVMYROUAONIZG2VQGKI6XCE4MJBDQ/ > 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/JNZHANDMQCYNF65RUOE3XKEEAPWYE54X/ Code of Conduct: http://python.org/psf/codeofconduct/
