[Python-Dev] some minor questions about pep8

[Donald Stufft]

> On Mar 21, 2015, at 5:17 PM, MRAB <python at mrabarnett.plus.com> wrote:
> 
> 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.

This is likely better solved by something like https://semver.org/ which is similar to what many people do already:

X.Y.Z+1 == Bug fixes only, should be backwards compatible.
X.Y+1.0 == New features, should be backwards compatible but comes with new things.
X+1.0.0 == Backwards Compatibility Break (Something deleted or changed)

> 
>>> 
>>>> 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?
>>> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/donald%40stufft.io

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150321/be201c29/attachment.sig>