[Distutils] PEP440: >1.7 vs >=1.7
ncoghlan at gmail.com
Sun Dec 28 15:57:08 CET 2014
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
>>>> with bothers me more, especially since I don't believe many people
>>>> even *use* a bare > and any alternative I can come up with has worse
>>>> for operators which get much more use.
>>> what about making >=,<= also use the series concept? where does that go
>> 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
>> 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
>> and given that I don't think people would expect >=1.7.0 to _not_match
>> I totally agree that the behavior of > isn't the greatest, I don't think
>> solution to that problem is to globally apply that particular wart. The
>> *reasonable* solutions I can think of are:
>> 1. Make < and > both act as simple comparison operators, and have >1.7
>> >1.7.0 both allow 1.7.1. This would include also allowing 1.7.dev0 to
>> <1.7 and <1.7.0.
>> 2. Make < and > both act as "exclusive comparison operators", and which
>> the current behavior.
>> 3. Make < and > both act as simple comparison operators, but include a
>> case that < does not ever match pre-releases of the version mentioned
>> the specifier. So <3 would not match a pre-released like 3.dev0, and
>> would not match a pre-release like 3.1.dev0 but would match a
>> like 3.0.dev0.
>> It may be that the correct solution is to just treat pre-releases as
>> and just switch to 3.
> After thinking about this some more, I made a PR that adjusts the
> library so that is has semantics which might be better overall than what
> currently in PEP 440. This PR is at
> 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
> * 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
Given the next bullet point, it sounds like this may have been another
symptom of incorrectly limiting the release segment zero padding to version
> * 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
> 2. A >V does not match a post-release of V unless V is itself a
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG