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 <[email protected]> wrote: > On Sun, Dec 28, 2014 at 1:20 PM, Marcus Smith <[email protected]> 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 - [email protected] >> https://mail.python.org/mailman/listinfo/distutils-sig >> > _______________________________________________ > Distutils-SIG maillist - [email protected] > https://mail.python.org/mailman/listinfo/distutils-sig _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
