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