> On Mar 21, 2015, at 5:17 PM, MRAB <pyt...@mrabarnett.plus.com> wrote: > > On 2015-03-21 21:00, Donald Stufft wrote: >> >>> On Mar 21, 2015, at 4:53 PM, Barry Warsaw <ba...@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@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
