On Wed, 14 Apr 2021 at 21:59, David Mertz
On Wed, Apr 14, 2021 at 9:12 PM Paul Moore
wrote: 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.
Are you suggesting that users should have to install an external module to tell what version of packages they are using?!
No. To tell what version of a package they are using, a string is sufficient. They only need a version object if they want to do additional processing (like comparing versions, or checking whether a version meets a constraint). Given that the packaging ecosystem already has a canonical version object (provided by the packaging library), which has been used and tested extensively in many environments, inventing a different API seems at best ill-advised. Whether the stdlib needs a version object. rather than leaving that functionality to a 3rd party library, is the same question that comes up for *any* functionality that's proposed for the stdlib, and I have no particular opinion in this case.
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?
Doesn't that seem really, really painful to use in an interactive shell? This is honestly (a simplified version of) what I tried in trying to learn packaging.version.Version. It was not a good experience:
It's designed for programmatic use, not interactive use, yes. But that's sort of my point, why do you want anything more than the bare string in the REPL? What are you planning on doing with it? Paul