On Wed, Apr 14, 2021 at 5:24 AM Victor Stinner <vstin...@python.org> wrote:
> There are two main use cases for versions: > > * Display them to the user > * Compare versions to check if one is newer, older or the same > > I dislike using strings for comparison. You need to use > packaging.version for that: > https://packaging.pypa.io/en/latest/version.html Yes, though it looks a little too heavyweight to be required, nifty features like ``is_prerelease` is going pretty far. On the other hand, maybe no harm in all that, as long as: - It's easy to do the easy stuff (which is looks like it is) - It would be added to the stdlib However, there is a lot of code out there that's already using strings for __version__, so it would be a real shame if we had to ask everyone to upgrade. And Version isn't going to be in older versions of the Python stdlib, so hard to make code compatible. But: If we make a Version object that can be compared to (confoming) strings then there might be a path forward. > In my Python projects, I like to provide the version as a tuple which > can be used directly for comparison: version_a <= version_b. Example: > Yes, and tuples are already built in to Python, so an easier lift than adding the Version object. Another possible issue: using Version would require an extra import in many module initializations -- is that a performance issue that would matter? In any case, I think the PEP should specify a standard for what is in __version__ And ideally it would be backward compatible with strings, which are the most commonly used currently. And conform to PEP 440 Sadly, such tuple is no standardized. Which > part is the major version? How to format it as a string? > > Good luck with trying to standardize that ;-) > well, PEP 440 gets us close -- and I *think* compliant strings could be unambiguously converted to-from tuples. Anyway, the question now for me is whether this is worth any more of my time. So: - Is there someone willing to sponsor? - Do folks generally think there's a chance of it being accepted without a huge debate and expansion of scope. If the answers are not yes, I can better spend my Python time of other things. BTW: one source of hope: __version__ strings are pretty common, but, as evidenced already by this brief discussion, it's not by any means a universal standard -- so we really can't break anything that already works in any universal way. What i mean by that is that anything done here might break someone's special use case of __version__ (Like the one David Mertz identified), but that scheme only works with that one package's code anyway. There are no general tools that expect that scheme. And it could be preserved by making a subclass of Version (Or str) that was also a mapping :-) - CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/QUJ6ESEXT2F3OWQIFG4ZFC4RT3CRRPCG/ Code of Conduct: http://python.org/psf/codeofconduct/
