[prev in list] [next in list] [prev in thread] [next in thread]
List: python-distutils-sig
Subject: Re: [Distutils] PEP440: >1.7 vs >=1.7
From: Nick Coghlan <ncoghlan () gmail ! com>
Date: 2014-12-29 22:57:07
Message-ID: CADiSq7cvNN_z-tzJafV9SHb+xwQ8UtUFPxGTxFFkg=UEud24cA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On 30 December 2014 at 05:09, Chris Jerdonek <chris.jerdonek@gmail.com>
wrote:
> On Mon, Dec 29, 2014 at 12:01 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
> > * for those cases (like date-based versions) where excluding releases
> with
> > an additional numeric suffix is the right thing to do, an explicit prefix
> > exclusion will still be possible, and will have the advantage of failing
> > noisily on older versions of pip and easy_install, rather than silently
> > installing an unexpected version (which is what will happen for anyone
> that
> > starts relying on the current explicit exclusion in PEP 440). It's also
> > possible to replace the exclusive bound with an inclusive bound that has
> the
> > last release segment component incremented.
>
> Just to confirm, in each of the below is it true that the two
> comparisons are exactly equivalent (taking into account pre-release
> and post-release rules, etc)?
>
> 1) >V.N.* and >=V.N+1
> 2) <=V.N.* and <V.N+1
>
If you omit the trailing ".*" (which isn't part of PEP 440 in the context
of ordered comparisons), then the following are equivalent in the currently
published version of the PEP:
1) "> V.N" and ">= V.N+1"
2) "<= V.N" and "< V.N+1"
The current behaviour of those exclusive comparisons is the part that's
both incompatible with the previous behaviour of setuptools/pkg_resources,
and somewhat confusing (largely because the interaction between the zero
padding and the negative prefix matching means that the trailing zero in
the release segment effectively isn't implied when comparing against
maintenance releases).
Donald's proposed adjustment at
https://github.com/pypa/interoperability-peps/pull/3 (which I now agree
with) changes them to be different: unlike ">= V.N+1", "> V.N" will once
again allow "V.N.x" maintenance releases, as it did in
setuptools/pkg_resources releases prior to 8.0.
The exclusive ordered comparison behaviour in the originally accepted
version of the PEP can still be requested explicitly as "< V, != V.*" and
"> V, != V.*" (where the latter has the virtue of failing noisily on older
versions of pkg_resources, rather than silently referring to a different
minimum version).
And these two should be even easier:
>
> 3) <V.* and <V
> 4) >=V.* and >=V
>
> With the way the PEP is written, it's not completely obvious to me
> that these are true.
>
In a hypothetical future version of the PEP that allowed the ".*" wildcard
suffix for ordered comparisons, it would likely have the following
semantics:
"< V.*" ==> "< V, != V.*"
"> V.*" ==> "> V, != V.*"
"<= V.*" ==> "<= V"
">= V.*" ==> ">= V"
However, it's not clear that such an addition would be worth it, given the
updated definition of exclusive comparisons, and the availability of the
more explicit spelling.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 30 December 2014 \
at 05:09, Chris Jerdonek <span dir="ltr"><<a \
href="mailto:chris.jerdonek@gmail.com" \
target="_blank">chris.jerdonek@gmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><span class="">On Mon, Dec 29, 2014 at 12:01 AM, \
Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> \
wrote:<br> > * for those cases (like date-based versions) where excluding releases \
with<br> > an additional numeric suffix is the right thing to do, an explicit \
prefix<br> > exclusion will still be possible, and will have the advantage of \
failing<br> > noisily on older versions of pip and easy_install, rather than \
silently<br> > installing an unexpected version (which is what will happen for \
anyone that<br> > starts relying on the current explicit exclusion in PEP 440). \
It's also<br> > possible to replace the exclusive bound with an inclusive \
bound that has the<br> > last release segment component incremented.<br>
<br>
</span>Just to confirm, in each of the below is it true that the two<br>
comparisons are exactly equivalent (taking into account pre-release<br>
and post-release rules, etc)?<br>
<br>
1) >V.N.* and >=V.N+1<br>
2) <=V.N.* and <V.N+1<br></blockquote><div><br></div><div>If you omit the \
trailing ".*" (which isn't part of PEP 440 in the context of ordered \
comparisons), then the following are equivalent in the currently published version of \
the PEP:<br><br>1) "> V.N" and ">= V.N+1"<br> 2) \
"<= V.N" and "< V.N+1"<br><div><br></div><div>The current \
behaviour of those exclusive comparisons is the part that's both incompatible \
with the previous behaviour of setuptools/pkg_resources, and somewhat confusing \
(largely because the interaction between the zero padding and the negative prefix \
matching means that the trailing zero in the release segment effectively isn't \
implied when comparing against maintenance releases).<br><br></div><div>Donald's \
proposed adjustment at <a \
href="https://github.com/pypa/interoperability-peps/pull/3">https://github.com/pypa/interoperability-peps/pull/3</a> \
(which I now agree with) changes them to be different: unlike ">= \
V.N+1", "> V.N" will once again allow "V.N.x" maintenance \
releases, as it did in setuptools/pkg_resources releases prior to \
8.0.<br></div><div><br></div><div>The exclusive ordered comparison behaviour in the \
originally accepted version of the PEP can still be requested explicitly as \
"< V, != V.*" and "> V, != V.*" (where the latter has the \
virtue of failing noisily on older versions of pkg_resources, rather than silently \
referring to a different minimum \
version).</div><div></div><br></div><div></div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">
And these two should be even easier:<br>
<br>
3) <V.* and <V<br>
4) >=V.* and >=V<br>
<br>
With the way the PEP is written, it's not completely obvious to me<br>
that these are true.<br></blockquote><div><br></div></div>In a hypothetical future \
version of the PEP that allowed the ".*" wildcard suffix for ordered \
comparisons, it would likely have the following semantics:<br><br></div><div \
class="gmail_extra">"< V.*" ==> "< V, != \
V.*"<br></div><div class="gmail_extra"><div class="gmail_extra">"> \
V.*" ==> "> V, != V.*"<br></div><div \
class="gmail_extra">"<= V.*" ==> "<= V"<br></div><div \
class="gmail_extra">">= V.*" ==> ">= \
V"<br></div><br></div><div class="gmail_extra">However, it's not clear that \
such an addition would be worth it, given the updated definition of exclusive \
comparisons, and the availability of the more explicit spelling.<br \
clear="all"></div><div class="gmail_extra"><br></div><div \
class="gmail_extra">Cheers,<br>Nick.<br></div><div class="gmail_extra"><br>-- \
<br><div class="gmail_signature">Nick Coghlan | <a \
href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a> | Brisbane, \
Australia</div> </div></div>
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic