[Distutils] PEP440: >1.7 vs >=1.7
graffatcolmingov at gmail.com
Sun Dec 28 20:49:15 CET 2014
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 at gmail.com> wrote:
> On Sun, Dec 28, 2014 at 1:20 PM, Marcus Smith <qwcode at 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).
>> Distutils-SIG maillist - Distutils-SIG at python.org
> Distutils-SIG maillist - Distutils-SIG at python.org
More information about the Distutils-SIG