On Wed, 14 Apr 2021 22:23:44 +0100 Paul Moore
On Wed, 14 Apr 2021 at 21:59, David Mertz
wrote: 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.
Tangentially, until now projects could use distutils's LooseVersion if they wanted to compare version numbers reliably. With distutils being deprecated, they'll have to either depending on packaging (which is a large dependency just for comparison version numbers) or vendor packaging's Version class (which is doable but still some bothersome additional work). Regards Antoine.