# [Distutils] Requirent specifiers specified? :)

Phillip J. Eby pje at telecommunity.com
Thu Jun 22 22:36:10 CEST 2006

```At 04:08 PM 6/22/2006 -0400, Jim Fulton wrote:
>>>So given:    >1, <3, >5, <7
>>>You are sure that 4 is accepted?
>>
>>Scanning left to right, >1 is a lower bound and 4 is above it, so
>>that's a tentative accept.  Next we see <3, and it is an upper
>>bound, and we fall below it, so it is a sure accept at that point,
>>and we stop scanning.
>
>Huh? 4 is below 3?

Hm, somehow I got confused with 2.  It should say, <3 is an upper bound, 4
is above it, tentative reject.  >5 is a lower bound, 4 is below it, it's a
sure reject.  I think I copied 2 in from another example while editing.

>>>Given:  <2, <5
>>>Is 3 accepted or rejected?
>>
>><2, upper bound, 3 is above, tentative reject.  <5, upper bound, 3
>>is below it, sure accept.  (Intuitively -- at least for me -- <5 is
>>paired with >-infinity here.)
>
>OK.  I think that many people would find this non-obvious.

You keep missing the big picture.  The algorithm is designed to interpret a
*meaningful* list of versions *specified by a human*.  Humans are usually
not excessively redundant, and will thus tend to express a version
requirement in the form of ranges with exceptions.

Humans tend to think that it is obvious that if they ask for a version <5,
they do not need to also specify that the version be more than negative
infinity, or even that it be greater than zero.  It is, after all, a
*version* number.  :)

Similarly, if I ask for a version >10, I assume that you will understand I
want it to be less than negative infinity.  :)

If it weren't for the fact that '.' and '-' are often used in version
numbers, I might have used range expressions using '-' or '...', but these
are also harder to read for the most common case where you want
'>=someversion'.

>Ah, so in your explanation above, "f the version falls below a lower
>bound"
>only applies to a scanning position.  OK, that clarifies this case.

If you look back at my previous descriptions, the concept of scanning is
repeated many times, including the simple 1-paragraph description.  It's
all scanning, just like a human would do when reading a series of version
requirements.

>I think that the fact that you need to understand a non-trivial
>algorithm
>with a state machine to understand how non-trivial specifications are
>interpreted is a problem.

It's only a problem if you try to reduce it to an algorithm.  If you simply
try to *understand* a version requirement, it's really quite
straightforward.  Think of what the human who wrote the requirement is saying:

"Um, let's see, it should be less than version 3, because that version's
got a new API, and it should be more than version 1.2, because there were
some bugfixes, and oh yeah, don't use version 1.6 because it was just plain
hosed.  Oh, and 1.1.3 is also good."

The algorithm is designed to correctly interpret a person who is simply
recording their wishes in this manner -- describing a series of acceptable
or unacceptable ranges, and mentioning specific versions that are
exceptions to the ranges.

>   Maybe it's enough to tell people "don't
>use complex specifications", but maybe it would be better to use a
>simpler system.

People don't normally express themselves redundantly -- especially
programmers.  The target users of specifications are these humans, not the
programmers trying to interpret the specification for specifications.  I
did not anticipate that particular user and use case.  ;)

```