On Wed, 14 Apr 2021 at 18:01, David Mertz <me...@gnosis.cx> wrote: > > On Wed, Apr 14, 2021 at 5:44 PM Christopher Barker <python...@gmail.com> > wrote: >> >> Another possible issue: using Version would require an extra import in many >> module initializations -- is that a performance issue that would matter? > > > I like having a `Version` object that is easily importable in the standard > library. I think it should relatively polymorphic. I.e. it should accept a > module or package as an argument, but also should accept a string or a tuple. > Maybe other objects from which one could reasonably extract a version.
If it's not basically equivalent to packaging.version.Version (and based on PEP 440) then we'll be creating a nightmare of confusion, because PEP 440 versions are fundamental to packaging. > In particular, I think initializing this object with a module object should > at least look for a .__version__ attribute, and appropriately case either a > string (that looks sufficiently version-like) or a tuple. I think that if it > doesn't succeed, it should become some sort of "cannot determine" object that > is neither less than nor greater than any other Version object. In > particular, the Vaex example with a dictionary of versions of each component > should probably just become this "cannot determine" value (but as an instance > of Version). What's wrong with Version(module.__version__)? And if the __version__ attribute isn't a valid version, raise an exception? That's what packaging.version does, and it's worked fine for the packaging ecosystem. Is there a benefit that justifies being different here? Can I remind people that the packaging community have done a *huge* amount of work designing and standardising concepts like version identifiers, version comparisons and constraints, etc. (PEPs 440 and 508). Understanding those standards should really be the basic starting point for any discussion like this. Paul _______________________________________________ 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/U2PUBZZ2AULMULLESO3LZ74MCRV7BQ3G/ Code of Conduct: http://python.org/psf/codeofconduct/
