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.
additional work).
Antoine.