Mailman 3 Remove module's __version__ attributes in the stdlib - Python-Dev

Remove module's version attributes in the stdlib

Serhiy Storchaka

14 Oct 2020 14 Oct '20

6:53 a.m.

Some module attributes in the stdlib have attribute __version__. It makes sense if the module is developed independently from Python, but after inclusion in the stdlib it no longer have separate releases which should be identified by version. New changes goes into module usually without changing the value of __version__. Different versions of the module for different Python version can have different features but the same __version__. I propose to remove __version__ in all stdlib modules. Are there any exceptions? Also, what do you think about other meta attributes like __author__, __credits__, __email__, __copyright__, __about__, __date__?

Show replies by date

Victor Stinner

14 Oct 14 Oct

8:42 a.m.

Hi, I was always confused by the __version__ variable of *some* modules. It's surprising since it's no longer incremented when the module is fixed or gets new features. Also, the number is unrelated to the Python version. I suggest to remove __version__. __author__, __credits__, __email__, __copyright__: can these information be kept as *comments*? __date__: what is that? Is it still relevant in 2020 since Python uses Git? I suggest removing it. For modules even have a changelog. Should it be removed since it is no longer updated for years? Many of these variables are ghosts from the early CVS time of Python :-) Victor Le mer. 14 oct. 2020 à 15:57, Serhiy Storchaka a écrit :

...

Some module attributes in the stdlib have attribute __version__. It makes sense if the module is developed independently from Python, but after inclusion in the stdlib it no longer have separate releases which should be identified by version. New changes goes into module usually without changing the value of __version__. Different versions of the module for different Python version can have different features but the same __version__.

I propose to remove __version__ in all stdlib modules. Are there any exceptions?

Also, what do you think about other meta attributes like __author__, __credits__, __email__, __copyright__, __about__, __date__? _______________________________________________ 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/KBU4EU2J... Code of Conduct: http://python.org/psf/codeofconduct/

-- Night gathers, and now my watch begins. It shall not end until my death.

Guido van Rossum

8:44 a.m.

None of these have seen much adoption, so I think we can lose them without dire consequences. The info should be moved into a docstring or comment. On Wed, Oct 14, 2020 at 06:54 Serhiy Storchaka wrote:

...

Some module attributes in the stdlib have attribute __version__. It makes sense if the module is developed independently from Python, but after inclusion in the stdlib it no longer have separate releases which should be identified by version. New changes goes into module usually without changing the value of __version__. Different versions of the module for different Python version can have different features but the same __version__.

I propose to remove __version__ in all stdlib modules. Are there any exceptions?

Also, what do you think about other meta attributes like __author__, __credits__, __email__, __copyright__, __about__, __date__? _______________________________________________ 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/KBU4EU2J... Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido (mobile)

Brett Cannon

10:56 a.m.

I think if the project is not maintained externally and thus synced into the stdlib we can drop the attributes. On Wed, Oct 14, 2020 at 8:44 AM Guido van Rossum wrote:

...

None of these have seen much adoption, so I think we can lose them without dire consequences. The info should be moved into a docstring or comment.

On Wed, Oct 14, 2020 at 06:54 Serhiy Storchaka wrote:

...
Some module attributes in the stdlib have attribute __version__. It makes sense if the module is developed independently from Python, but after inclusion in the stdlib it no longer have separate releases which should be identified by version. New changes goes into module usually without changing the value of __version__. Different versions of the module for different Python version can have different features but the same __version__.

I propose to remove __version__ in all stdlib modules. Are there any exceptions?

Also, what do you think about other meta attributes like __author__, __credits__, __email__, __copyright__, __about__, __date__? _______________________________________________ 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/KBU4EU2J... Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido (mobile) _______________________________________________ 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/RGHWIBDQ... Code of Conduct: http://python.org/psf/codeofconduct/

Serhiy Storchaka

15 Oct 15 Oct

12:15 p.m.

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.

Karthikeyan

9:26 p.m.

On Fri, Oct 16, 2020, 12:45 AM Serhiy Storchaka 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-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/MIEMWWC5... Code of Conduct: http://python.org/psf/codeofconduct/

Steve Holden

16 Oct 16 Oct

3:07 a.m.

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? Kind regards, Steve On Fri, Oct 16, 2020 at 5:28 AM Karthikeyan wrote:

...

On Fri, Oct 16, 2020, 12:45 AM Serhiy Storchaka 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-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/MIEMWWC5... Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ 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/3NY5JIFU... Code of Conduct: http://python.org/psf/codeofconduct/

Brett Cannon

12:18 p.m.

On Fri, Oct 16, 2020 at 3:08 AM Steve Holden 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 wrote:

...
On Fri, Oct 16, 2020, 12:45 AM Serhiy Storchaka 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-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/MIEMWWC5... Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ 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/3NY5JIFU... Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ 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/JZ4JVMYR... Code of Conduct: http://python.org/psf/codeofconduct/

Neil Schemenauer

14 Oct 14 Oct

11:23 a.m.

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.

Batuhan Taskaya

1:25 p.m.

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%27cg... 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-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/MI2SLQCZ... Code of Conduct: http://python.org/psf/codeofconduct/

Victor Stinner

15 Oct 15 Oct

4:59 a.m.

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 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%27cg... 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-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/MI2SLQCZ... Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ 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/MSQTTUZO... Code of Conduct: http://python.org/psf/codeofconduct/

-- Night gathers, and now my watch begins. It shall not end until my death.

Serhiy Storchaka

11:59 a.m.

15.10.20 14:59, Victor Stinner пише:

...

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).

This is a good idea, I though about it. But it seems that there are no usages the __version__ variable in top 4K pypi packages.

Neil Schemenauer

12:17 p.m.

On 2020-10-15, Serhiy Storchaka wrote:

...

[..] it seems that there are no usages the __version__ variable in top 4K pypi packages.

Given that, I think it's fine to remove them. If we find broken code during the alpha release we still have a chance to revert. However, it would seem quite unlikely there would be a problem. Thanks to Batuhan for the useful search tool.

Serhiy Storchaka

11:34 a.m.

14.10.20 23:25, Batuhan Taskaya пише:

...

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

As for argparse, it was perhaps the last third-party module added to the stdlib without changing name and significant rewriting. It was added in Python 2.7/3.2, and older Python versions are not maintained for long time. There is a third-party module argparse on PyPI for older Python versions, its version 1.4 is higher that the version in the stdlib (1.1), but I think that the stdlib version has more features. The version of the module is just not informative.

...

|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%27cg...

Thank you Batuhan. It will help to decide what to do with __version__ attributes: keep them ,upgrade to sys.version or sys.version_info, remove.

Serhiy Storchaka

11:57 a.m.

14.10.20 23:25, Batuhan Taskaya пише:

...

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__|

If it refers to the third-party argparse module, which uses argparse.__version__ in its setup.py, it is __version__ of that third-party module, not the one from the stdlib.

...

rawdata/pypi/junitparser-1.4.1/bin/junitparser

|argparse.__version__|

argparse.__version__ is used for displaying the version of the junitparser script. Of course the version of argparse (1.1 in the stdlib) does not have any relation with the version of junitparser (currently 1.4.1), so this is purely a misuse.

...

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.

So it seems that there is only one usage of __version__ from the stdlib modules, and that that one is a bug. Reported. It seems pretty safe to just remove __version__ variables.

Erlend Aasland

5:45 a.m.

FYI, sqlite3 has a pysqlite “version" attribute iso. “__version__", stemming from its days outside of stdlib. It has held the value “2.6.0" since commit f9cee22, 2010-03-05. Erlend E. Aasland On 14 Oct 2020, at 15:53, Serhiy Storchaka mailto:storchaka@gmail.com> wrote: Some module attributes in the stdlib have attribute __version__. It makes sense if the module is developed independently from Python, but after inclusion in the stdlib it no longer have separate releases which should be identified by version. New changes goes into module usually without changing the value of __version__. Different versions of the module for different Python version can have different features but the same __version__. I propose to remove __version__ in all stdlib modules. Are there any exceptions? Also, what do you think about other meta attributes like __author__, __credits__, __email__, __copyright__, __about__, __date__? _______________________________________________ Python-Dev mailing list -- python-dev@python.orgmailto:python-dev@python.org To unsubscribe send an email to python-dev-leave@python.orgmailto: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/KBU4EU2J... Code of Conduct: http://python.org/psf/codeofconduct/

Erlend Aasland

5:47 a.m.

Actually both sqlite3.version and sqlite3.version_info, the former as a string, the latter as a tuple. E On 15 Oct 2020, at 14:45, Erlend Aasland mailto:Erlend-A@innova.no> wrote: FYI, sqlite3 has a pysqlite “version" attribute iso. “__version__", stemming from its days outside of stdlib. It has held the value “2.6.0" since commit f9cee22, 2010-03-05. Erlend E. Aasland On 14 Oct 2020, at 15:53, Serhiy Storchaka mailto:storchaka@gmail.com> wrote: Some module attributes in the stdlib have attribute __version__. It makes sense if the module is developed independently from Python, but after inclusion in the stdlib it no longer have separate releases which should be identified by version. New changes goes into module usually without changing the value of __version__. Different versions of the module for different Python version can have different features but the same __version__. I propose to remove __version__ in all stdlib modules. Are there any exceptions? Also, what do you think about other meta attributes like __author__, __credits__, __email__, __copyright__, __about__, __date__? _______________________________________________ Python-Dev mailing list -- python-dev@python.orgmailto:python-dev@python.org To unsubscribe send an email to python-dev-leave@python.orgmailto: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/KBU4EU2J... Code of Conduct: http://python.org/psf/codeofconduct/

Paul Moore

8:37 a.m.

On Thu, 15 Oct 2020 at 16:31, Erlend Aasland wrote:

...

Actually both sqlite3.version and sqlite3.version_info, the former as a string, the latter as a tuple.

However, sqlite3.sqlite_version and sqlite3.sqlite_version_info should definitely be retained, as they give the version of the sqlite library Python is using. (In general, I'm ambivalent about removing version attributes - I agree that they are basically useless, but there's little gain from removing them, and there's the risk of breaking code for essentially no reason. If we're looking to tidy things up, I'm fairly sure there are better candidates than this...) Paul

Ethan Furman

9:24 a.m.

On 10/15/20 5:45 AM, Erlend Aasland wrote:

...

FYI, sqlite3 has a /pysqlite/ “version" attribute iso. “__version__", stemming from its days outside of stdlib. It has held the value “2.6.0" since commit f9cee22, 2010-03-05.

The proposal is to remove dunder version and friends, not plain version and friends. Or did you mean it should also be removed? -- ~Ethan~ * iso. => instead of

1285

Age (days ago)

1287

Last active (days ago)

List overview

Download

18 comments

11 participants

participants (11)

Batuhan Taskaya
Brett Cannon
Erlend Aasland
Ethan Furman
Guido van Rossum
Karthikeyan
Neil Schemenauer
Paul Moore
Serhiy Storchaka
Steve Holden
Victor Stinner

Remove module's __version__ attributes in the stdlib

tags

participants (11)

Remove module's version attributes in the stdlib