[Python-Dev] some minor questions about pep8

MRAB python at mrabarnett.plus.com
Sat Mar 21 22:17:26 CET 2015


On 2015-03-21 21:00, Donald Stufft wrote:
>
>> On Mar 21, 2015, at 4:53 PM, Barry Warsaw <barry at 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?
>>



More information about the Python-Dev mailing list