On Sat, Nov 28, 2009 at 4:00 AM, P.J. Eby <pje@telecommunity.com> wrote:
At 12:26 PM 11/28/2009 +1100, Ben Finney wrote:
I think you're reading a proposal that I didn't write.
Are you not the person who's proposed using simple alphanumeric strings for version comparison?
My understanding of PEP 386 is that it *isn't* about asking Python developers to change how they work. Is that not right?
Asking them to generate alternative versioning schemes, without the ability to use pre-release versions (e.g. alpha, beta, etc.) would most certainly be a change from the status quo.
Moreover, what is a standard for if not for encouraging people to follow it for the benefit of many?
Usually, they get something in trade. Supporting WSGI means you get to use WSGI apps, or run on a WSGI server, for example. So, cost and benefit are balanced.
In contrast, a popular Python library or app will get packaged if somebody wants it, and not if they don't. There isn't a lot of incentive for a developer to do something different, solely for the sake of the packager... which is probably why things are the way they are now.
If, on the other hand, there's some positive benefit being offered (e.g. a new tool that makes life easier for them or perhaps their users), then there might be some incentive to learn a new way of coding versions. But without such an incentive, who wants to learn some new way to encode prerelease versions?
This is why I've argued for keeping a scheme in 386 that can mechanically translate most existing versioning schemes found in the wild: it means that most people won't have to do a thing, as tool builders can just use suggest_version().
Yes, this function can be used internally, and that was a good idea to have that function. But as soon as it is used inside a public package manager, like pip or setuptools or distribute, I expect this function to raise some kind of warning so the developers knows its version doesn't meet the public, documented standard.