On Fri, Mar 18, 2011 at 07:40:43PM -0700, Guido van Rossum wrote: > On Fri, Mar 18, 2011 at 7:28 PM, Greg Ewing <[email protected]> > wrote: > > Tres Seaver wrote: > > > >> I'm not even sure why you would want __version__ in 99% of modules: in > >> the ordinary cases, a module's version should be either the Python > >> version (for a module shipped in the stdlib), or the release of the > >> distribution which shipped it. > > > > It's useful to be able to find out the version of a module > > you're using at run time so you can cope with API changes. > > > > I had a case just recently where the behaviour of something > > in pywin32 changed between one release and the next. I looked > > for an attribute called 'version' or something similar to > > test, but couldn't find anything. > > > > +1 on having a standard place to look for version info. > > I believe __version__ *is* the standard (like __author__). IIRC it was > proposed by Ping. I think this convention is so old that there isn't a > PEP for it. So yes, we might as well write it down. But it's really > nothing new. > There is a section in PEP8 about __version__ but it serves a slightly different purpose there:
"""
Version Bookkeeping
If you have to have Subversion, CVS, or RCS crud in your source file, do
it as follows.
__version__ = "$Revision: 88433 $"
# $Source$
These lines should be included after the module's docstring, before any
other code, separated by a blank line above and below.
"""
Personally, I've never found a need to access the repository revision
programatically from my pyhon applications but I have needed to access the
API version so it would make sense to me to change the meaning of
__version__.
-Toshio
pgpr66xyWCYYt.pgp
Description: PGP signature
_______________________________________________ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
