On 28 Dec 2014 17:12, "Donald Stufft" <donald@stufft.io> wrote:
On Dec 27, 2014, at 9:26 PM, Donald Stufft <donald@stufft.io> wrote:
On Dec 27, 2014, at 9:10 PM, Marcus Smith <qwcode@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 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
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
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
come up the pre-release 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)
* 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
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. pre-release. 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.