Mailing List Archive

Remove module's __version__ attributes in the stdlib
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/KBU4EU2JULXSMUZULD5HJJWCGOMN52MK/
Code of Conduct: http://python.org/psf/codeofconduct/
Re: Remove module's __version__ attributes in the stdlib [ In reply to ]
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 <storchaka@gmail.com> 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/KBU4EU2JULXSMUZULD5HJJWCGOMN52MK/
> 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-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/HH726TXVDUF4GSTUJALKU3WT5LIQNOAZ/
Code of Conduct: http://python.org/psf/codeofconduct/
Re: Remove module's __version__ attributes in the stdlib [ In reply to ]
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 <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.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/KBU4EU2JULXSMUZULD5HJJWCGOMN52MK/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido (mobile)
Re: Remove module's __version__ attributes in the stdlib [ In reply to ]
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 <guido@python.org> 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 <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.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/KBU4EU2JULXSMUZULD5HJJWCGOMN52MK/
>> 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/RGHWIBDQJOHRUM726BR2WYZOBO2T5WIY/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
Re: Remove module's __version__ attributes in the stdlib [ In reply to ]
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/MI2SLQCZIKBRFX7HCUB7G4B64MTZ6XVC/
Code of Conduct: http://python.org/psf/codeofconduct/
Re: Remove module's __version__ attributes in the stdlib [ In reply to ]
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-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/MI2SLQCZIKBRFX7HCUB7G4B64MTZ6XVC/
> Code of Conduct: http://python.org/psf/codeofconduct/
Re: Remove module's __version__ attributes in the stdlib [ In reply to ]
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 <isidentical@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-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/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-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/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-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/WTTUGC7RQZLV6XQPVQAV4RVELNLAIATM/
Code of Conduct: http://python.org/psf/codeofconduct/
Re: Remove module's __version__ attributes in the stdlib [ In reply to ]
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 <storchaka@gmail.com<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.org<mailto:python-dev@python.org>
To unsubscribe send an email to python-dev-leave@python.org<mailto: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/KBU4EU2JULXSMUZULD5HJJWCGOMN52MK/
Code of Conduct: http://python.org/psf/codeofconduct/
Re: Remove module's __version__ attributes in the stdlib [ In reply to ]
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 <Erlend-A@innova.no<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 <storchaka@gmail.com<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.org<mailto:python-dev@python.org>
To unsubscribe send an email to python-dev-leave@python.org<mailto: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/KBU4EU2JULXSMUZULD5HJJWCGOMN52MK/
Code of Conduct: http://python.org/psf/codeofconduct/
Re: Remove module's __version__ attributes in the stdlib [ In reply to ]
On Thu, 15 Oct 2020 at 16:31, Erlend Aasland <Erlend-A@innova.no> 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
_______________________________________________
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/6PUP4FORLNX4TAEET42C6YN4SGR22SSU/
Code of Conduct: http://python.org/psf/codeofconduct/
Re: Remove module's __version__ attributes in the stdlib [ In reply to ]
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
_______________________________________________
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/W2VCBOOS7NSUMEDBO7UOB22Z3CBVZIV5/
Code of Conduct: http://python.org/psf/codeofconduct/
Re: Remove module's __version__ attributes in the stdlib [ In reply to ]
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%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

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.
_______________________________________________
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/XAHSO7AUX5J7MDXFDXUAHYAAWF7WH4JZ/
Code of Conduct: http://python.org/psf/codeofconduct/
Re: Remove module's __version__ attributes in the stdlib [ In reply to ]
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.
_______________________________________________
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/GRJTXCRUDEUQZE2IYSBKFJYKGS7AXZXA/
Code of Conduct: http://python.org/psf/codeofconduct/
Re: Remove module's __version__ attributes in the stdlib [ In reply to ]
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.
_______________________________________________
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/LBHVJIXGG3U5FPOYYOTS6AG3KPSLHBER/
Code of Conduct: http://python.org/psf/codeofconduct/
Re: Remove module's __version__ attributes in the stdlib [ In reply to ]
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.
_______________________________________________
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/MIEMWWC5W2WKV25WTARXACQOIUBUUSLS/
Code of Conduct: http://python.org/psf/codeofconduct/
Re: Remove module's __version__ attributes in the stdlib [ In reply to ]
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.
_______________________________________________
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/7BX4J3LSTFFGQ4GCB5EGN552ZLVOBCSR/
Code of Conduct: http://python.org/psf/codeofconduct/
Re: Remove module's __version__ attributes in the stdlib [ In reply to ]
On Fri, Oct 16, 2020, 12:45 AM Serhiy Storchaka <storchaka@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-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/MIEMWWC5W2WKV25WTARXACQOIUBUUSLS/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
Re: Remove module's __version__ attributes in the stdlib [ In reply to ]
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 <tir.karthi@gmail.com> wrote:

> On Fri, Oct 16, 2020, 12:45 AM Serhiy Storchaka <storchaka@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-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/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-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/3NY5JIFUP5674Q3FR2DOMLXGBE6D4XJD/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
Re: Remove module's __version__ attributes in the stdlib [ In reply to ]
On Fri, Oct 16, 2020 at 3:08 AM Steve Holden <steve@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.karthi@gmail.com> wrote:
>
>> On Fri, Oct 16, 2020, 12:45 AM Serhiy Storchaka <storchaka@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-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/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-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/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-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/JZ4JVMYROUAONIZG2VQGKI6XCE4MJBDQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>