I think you are making a mistake to assume that everyone has the same notion of obvious that you do. For example, someone could reasonably expect that ==1.0 matches 1.1.1. (I'm not advocating this interpretation, but simply pointing out that "obvious" is not universal.) In addition, people sometimes make typos. A system that figures out what they "really meant" rather than complain when they enter something that doesn't make sense isn't doing them any favors. In any case, I expect that having people build tools on top of setuptools is a use case you anticipated. For people to do that, they sometimes need precise specifications of behavior. Jim On Jun 22, 2006, at 4:36 PM, Phillip J. Eby wrote:
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. ;)
-- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org