On 16/03/2011 15:00, Raymond Hettinger wrote:
On Mar 16, 2011, at 11:33 AM, R. David Murray wrote:
On Wed, 16 Mar 2011 13:33:20 -0400, Michael Foord<fuzzy...@voidspace.org.uk>
wrote:
On 16/03/2011 12:39, Alexander Belopolsky wrote:
I was editing the turtle module (for issue11571, if you are
interested) when I noticed that it has the following line:
_ver = "turtle 1.1b- - for Python 3.1 - 4. 5. 2009"
unittest also has an outdated (and unmaintained) version number that I
would like to remove. Standard library modules should be versioned by
the release of Python they are packaged with (unless they are externally
maintained I guess) and so should preferably *not* carry version info.
The email package has an internal version (which changes no more often
than CPython's, but may change slower). Existing code in the field
tests this version attribute, so I don't think it should be deleted.
The version number in the decimal module refers to the version of the
spec that is being complied with. I would like that version number
to remain in the module.
There are probably other cases where the version number is useful.
That's entirely fair enough, although that's not really a *module
version number* so isn't what I was referring to. The sqlite module also
carries version information about the version of sqlite it works with
which is another valid use case (sqlite *also* has a module version
number I believe, because it is externally maintained).
In the case of the unittest version number it goes back to when unittest
*was* originally maintained externally.
As general practise is to use __version__ for module version info I
think it would be bad (misleading) if any module (including standard
library) reused this name for storing information that *wasn't* a module
version but some related version info.
All the best,
Michael
Raymond
--
http://www.voidspace.org.uk/
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
