[Python-ideas] Add support for version objects

[Paul Moore]

On 28 May 2016 at 05:38, Ethan Furman <ethan at stoneleaf.us> wrote:
> On 05/27/2016 08:22 PM, Nick Coghlan wrote:
>
>> The main advantage I'd see to stdlib inclusion is providing "one obvious
>> way to do it" - it isn't immediately obvious to a newcomer that PEP 440
>> and the implementation in packaging are the preferred approach for
>> SemVer-like version numbers in Python projects.
>
>
> Yup, I'll second that!

Agreed. Having a version object in the stdlib would be a good way of
directing people to the standard approach. Some points:

- It pretty much has to be PEP 440, as that's the standard in the
Python packaging ecosystem. Adding a *different* standard to the
stdlib would be a big problem IMO.
- Packaging tools like pip will still need to bundle an external
implementation (at the moment we use the "packaging" library) as
they'll need to support older versions of Python for some time yet. So
there would need to be a maintained backport version on PyPI (or the
packaging library could be sanctioned as that backport).
- Assuming a separate backport, it's not clear to me how we'd manage
the transition between packaging and the backport (maintain the 2 in
parallel? packaging falls back to the stdlib/backport if present?
packaging gains a conditional dependency on the backport?)
- PEP 440, and the implementation, is pretty stable. But are we happy
for it to move to the development pace of the stdlib?

The distutils version classes are pretty old, and fairly limited - the
strict version is frequently *too* strict, but the loose version is
rather too lenient...

Paul