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:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
