On 6/19/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: [Guido] > > I'm not so sure about there being no hidden surprises. I betcha that > > there are quire a few bits of code that curerntly use the if/elif > > style and seem to beg for a switch statement that depend on the > > ordering of the tests. A typical example would be to have one of the > > earlier tests express an exception to a later test that is a range > > test. > > That's a tricky issue. Whenever the cases overlap, I would expect a > successive comparison approach to jump to the first match while a hash > table approach would jump to the last match (just like a dictionary > retains only the latest (key,value) pair when fed successive pairs with > identical keys and differing values).
But it would be easy enough to define a dict-filling function that updates only new values. (PyDict_Merge has an option to do this, although it's not currently exposed to Python.) > > (Surely we're going to support range tests... sre_compile.py > > uses 'in' almost as often as 'is'.) > > When the ranges have a short length as they do in sre, I expect that the > syntax would allow the range to be captured on one line but have > multiple entries in the hash table which each dispatch to the same > target code suite: > > switch x: > case 0, 2, 4, 6: handle_even() > case 1, 3, 5, 9: handle_odd() > default: handle_fractions() Was it decided yet how to write the cases for a switch that tests for tuples of values? Requiring parentheses might be sufficient, essentially making what follows a case *always* take on sequence syntax. > Unfortunately, that approach is less than ideal for bigger ranges: > > switch x: > case xrange(0,sys.maxint,2): handle_odd() > case xrange(1,sys.maxint,2): handle_even() > default: handle_fractions() Right. This would be fine syntactically but clearly breaks the dict implementation... > Other types of range checks get us back into the area of arbitrary > expressions in case values and having to repeat the variable name: > > switch x: > case x < 60: return "too cold" > case 60 <= x < 80: return "just right" > case 80 <= x: return "too hot" > > Choose your poison. How much range flexibility do you want and how much > implementation and behavioral complexity are you willing to pay for it. In order to decide, we should look at current usage of long if/elif chains. > >> If use cases eventually emerge for an alternative path using successive > >> == comparisons, then it can always be considered and added later. For > >> now, YAGNI (neither the functionality, nor the implementation headaches, > >> nor the complexity of explaining what it does under all the various > >> cases). > > > > I say, let someone give a complete implementation a try, and then try > > to modify as much standard library code as possible to use it. Then > > report back. That would be a very interesting experiment to do. (And > > thanks for the pointer to sre_compile.py as a use case!) > > Hmm, it could be time for the Georg bot to graduate to big game. > Georg, are you up to it? Georg is a bot? :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com