"P.J. Eby"
That depends on whether this PEP's version scheme is also going to be embedded in the code implied by PEP 376. If so, then nobody will have any reason to switch from using pkg_resources to the PEP 376 pkgutil code, because they won't be able to manage their test, dev, and collaboration environments that way.
What prevents them from doing so merely by choosing version strings that conform to the specification?
That's precisely it - there aren't any visible benefits to doing so, but there *are* visible problems.
I think a significant benefit will be that the version comparison semantics will be implemented *in Python*, and I know there are very many people who would like to drop a dependency on third-party tools. Alternatively, if this version string scheme is to be implemented in PEP 365, that has the same effect: it will be “part of Python”, which is a huge benefit compared to an implementation outside Python.
We need to have a way to translate existing version schemes to the new one, if we're to be able to have a reasonable upgrade path --
This certainly deserves consideration. However, I remind readers that part of the problem we're trying to solve here is that version string schemes are *already* non-standard and inconsistent; we would have to choose only a sub-set of existing version schemes to be supported for upgrade. -- \ “In the long run, the utility of all non-Free software | `\ approaches zero. All non-Free software is a dead end.” —Mark | _o__) Pilgrim, 2006 | Ben Finney