On 28 May 2016 3:36 am, "Paul Moore" p.f.moore@gmail.com wrote:

On 28 May 2016 at 05:38, Ethan Furman ethan@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 other issue is the intended use case - I *think* PEP 440 (including the normalisation steps) will cover the version numbering for external dependencies like Tkinter and zlib, but it's not the precise context that spec was designed to cover (i.e. versioning distribution packages for Python projects).

I still think the idea is worth considering, it's just a more complex problem than it appears to be at first glance.

Cheers, Nick.

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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/