On Sunday, December 28, 2014, Ian Cordasco <[email protected]> wrote:
> 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. To add another wrinkle, do you think 2014.09.01 should or shouldn't match "<=2014.09"? This is an example of the case I mentioned at the end of my previous email. --Chris > > On Sun, Dec 28, 2014 at 1:43 PM, Chris Jerdonek > <[email protected] <javascript:;>> wrote: > > On Sun, Dec 28, 2014 at 1:20 PM, Marcus Smith <[email protected] > <javascript:;>> 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] <javascript:;> > >> https://mail.python.org/mailman/listinfo/distutils-sig > >> > > _______________________________________________ > > Distutils-SIG maillist - [email protected] <javascript:;> > > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
