On 2015-03-21 21:00, Donald Stufft wrote:
On Mar 21, 2015, at 4:53 PM, Barry Warsaw <barry@python.org> wrote:
On Mar 20, 2015, at 08:53 PM, Guido van Rossum wrote:
FWIW, I think __version__, __author__ etc. were bad ideas. Almost nobody manages these correctly. Note that the PEP 8 section starts with less than an endorsement: "If you *have* to have Subversion, CVS, or RCS crud in your source file, do it as follows."
I tend to agree. Individual module version numbers are mostly useless, especially with today's hash-based vcses.
That's different than package versions, and for which I really need to resurrect and update PEP 396.
I sort of think (though I haven’t completely convinced myself) that adding something like __version__ to a package is a work around to the fact that we don’t have an API that lets someone ask “what is the distribution and version that this module/import-package came from”.
Something like:
>>> import theorticalapi >>> import mymodule >>> >>> d = theorticalapi.module_dist(mymodule) >>> print(d.name) >>> mycustommodules >>> print(d.version) >>> 1.0
Since we (theoretically) should have all of this information already inside of the packaging metadata, we just don’t have a way to say “given a particular import, give me the information I want).
A bit OT (and should probably be in python-ideas), but I've come to think that it might be more helpful to have double version numbers. What do I mean by that? Well, an "addition" version that's increased when something is added, and a "deletion" version that's increased when something is removed. Suppose there's a new release of a module. If it has a higher "addition version", then something has been added, which won't affect existing code. If it has a higher "deletion version", then something has been removed, which _might_ affect existing code, so you'll need to check. If the code doesn't use what was removed, then you can accept the higher deletion version.
That said, if an official answer is required, common sense would suggest that __version__ should go before the imports. (I would put it before the docstring too, except then the docstring wouldn't be a docstring any more. Go figure.)
And after __future__ imports too, right?