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 provi
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 Storchak
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 t
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
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
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
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 (resul
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 (resul
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
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 l
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:erlen...@innova.no>> wrote:
FYI, sqlite3 has a pysqlite “version" attribute iso. “__version__", stemming
from its days outside of stdlib. It
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:storch...@gmail.com>> wrote:
Some module attribute
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.
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/argpar
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
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
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 mod
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__, __copy
18 matches
Mail list logo
