I personally think that 1.7.1 matching >1.7 muddies some applications of it being used with date-based versions with this pep also supports. This (as best I can tell) means that now 2014.09.31 will match > 2014.09 which seems like a rather terrible idea. No one expects a date to be padded with 0s. I'm also fully against special casing date-based versions because the whole point of 440 was to make versioning consistent and reliable and I wholeheartedly want that. On Sun, Dec 28, 2014 at 1:43 PM, Chris Jerdonek <chris.jerdonek@gmail.com> wrote:
On Sun, Dec 28, 2014 at 1:20 PM, Marcus Smith <qwcode@gmail.com> wrote:
* 1.7.1 matches >1.7 (previously it did not)
This sounds like a straight up bug fix in the packaging module to me - the PEP 440 zero padding should apply to *all* checks, not just to equality checks, as you can't sensibly compare release segments with different numbers of elements.
OK. to be clear, I guess you really didn't follow the previous thread? I specifically raised the concern over 1.7.1 not matching >1.7 (in the current implementation), but most people were arguing it was a logical interpretation of PEP440.
I think Nick's e-mail clarifies it for me.
In my e-mail, I was reconciling the current behavior with the current wording of the PEP, which says, "Exclusive ordered comparisons are similar to inclusive ordered comparisons, except that the comparison operators are < and > and the clause MUST be effectively interpreted as implying the prefix based version exclusion clause != V.*."
I now see that the wording is a bit ambiguous (or at least that I was misinterpreting it). I interpreted it to mean that prefix-based version exclusion should be used *instead* of zero-padding, whereas with Nick's e-mail, I see that the meaning is that prefix-based exclusion should be used *after* applying zero padding.
The clarified interpretation also addresses an asymmetry of the previously mentioned (and now apparently incorrect) "series" interpretation, which I'm not sure was mentioned before. Namely, 1.7.2 satisfies ">=1.7" but does not satisfy "<=1.7". With the series interpretation, the latter wouldn't be consistent (since 1.7.2 is part of the series under that interpretation).
--Chris
Marcus
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig