[Distutils] PEP440: >1.7 vs >=1.7

[Nick Coghlan]

On 28 Dec 2014 17:12, "Donald Stufft" <donald at stufft.io> wrote:
>
>
>> On Dec 27, 2014, at 9:26 PM, Donald Stufft <donald at stufft.io> wrote:
>>
>>
>>> On Dec 27, 2014, at 9:10 PM, Marcus Smith <qwcode at gmail.com> wrote:
>>>
>>>> In gives me a minor bit of pause. However any alternative that I can
come up
>>>> with bothers me more, especially since I don't believe many people
actually
>>>> even *use* a bare > and any alternative I can come up with has worse
behavior
>>>> for operators which get much more use.
>>>
>>>
>>> what about making >=,<= also use the series concept? where does that go
wrong?
>>>
>>
>> To be clear, you’re talking about doing something like:
>>
>> >1.7 is >1.7 AND !=1.7.* which would correlate to >1.7 OR ==1.7.*?
>>
>> Honestly, the thing that I dislike about that is it takes a behavior
which is
>> less intuitive (I do agree that the behavior of > is less intuitive) and
>> applies to globally. I don't think people would expect >=1.7 to match
1.7.dev0
>> and given that I don't think people would expect >=1.7.0 to _not_match
>> 1.7.dev0.
>>
>> I totally agree that the behavior of > isn't the greatest, I don't think
the
>> solution to that problem is to globally apply that particular wart. The
only
>> *reasonable* solutions I can think of are:
>>
>> 1. Make < and > both act as simple comparison operators, and have >1.7
and
>>    >1.7.0 both allow 1.7.1. This would include also allowing 1.7.dev0 to
be
>>    <1.7 and <1.7.0.
>>
>> 2. Make < and > both act as "exclusive comparison operators", and which
is
>>    the current behavior.
>>
>> 3. Make < and > both act as simple comparison operators, but include a
special
>>    case that < does not ever match pre-releases of the version mentioned
in
>>    the specifier. So <3 would not match a pre-released like 3.dev0, and
<3.1
>>    would not match a pre-release like 3.1.dev0 but would match a
pre-release
>>    like 3.0.dev0.
>>
>> It may be that the correct solution is to just treat pre-releases as
special
>> and just switch to 3.
>>
>
> After thinking about this some more, I made a PR that adjusts the
packaging
> library so that is has semantics which might be better overall than what
is
> currently in PEP 440. This PR is at
https://github.com/pypa/packaging/pull/25
> if someone wants to play with it at all, but the highlights are:
>
> * 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.

Hence this sentence in the description of the release segment under the
"Final releases" heading: "When comparing release segments with different
numbers of components, the shorter segment is padded out with additional
zeros as necessary."

The zero padding does get called out again explicitly in the section on
version matching, but that's in the context of explaining why "== 1.7" will
match "1.7.0" and vice-versa, even though version matching is otherwise
strict.

> * 1.7.post1 does not match >1.7 (previously it did not)
> * 1.7.post1 matches >1.7.post0 (previously it did)
> * 3.dev0 does not match <3.0 (previously it did)

This is another bug fix - avoiding that match is one of the key reasons for
the wildcard exclusion in the definition of the exclusive comparison
operators.

Given the next bullet point, it sounds like this may have been another
symptom of incorrectly limiting the release segment zero padding to version
matching operations.

> * 3.0.dev0 does not match <3.0 (previously it did not)
> * 3.0.dev0 matches <3.0rc1 (previously it did)
>
> Instead of having >V and <V impliy !=V.*, this means that:
>
> 1. A <V does not match a pre-release of V unless V is itself a
pre-release.
> 2. A >V does not match a post-release of V unless V is itself a
post-release.
> 3. A >V does not match a V+local.version.

Please don't make the change more complicated than it needs to be - there's
just a bug in the packaging implementation of the PEP semantics. Zero
padding of the release segment should be applied to all operations, and
that currently isn't happening.

Regards,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20141229/beac1b6b/attachment.html>