On 6/26/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > In http://mail.python.org/pipermail/python-dev/2006-June/066475.html > Nick Coghlan wrote: > > > (Unlike Jim, I have no problems with restricting switch statements to > > hashable objects and building the entire jump table at once - if what you > > want > > is an arbitrary if-elif chain, then write one!) > > I haven't been clear. I don't object to building the entire table at > once. I object to promising that this will happen, which forbids > other implementations from using certain optimizations. > > I would prefer something like: > > There is no guarantee on how often or when the case statements will be > evaluated, except that it will be after the enclosing scope exists and > before the relevant test is needed. If a case expression has side > effects, the behavior with respect to these side effects is explicitly > undefined.
This is the kind of language that makes C++ and Fortrans standards so difficult to interpret. I like Python's rules to be simple, and I prefer to occasionally close off a potential optimization path in the sake of simplicity. For example, I like left-to-right evaluation of operands and function arguments. The C++/Fortran style weasel words to allow optimizers to do sneaky stuff aren't really wort the trouble they can create in Python, where even the best optimization produces code that's much slower than C. In practice, most users observe the behavior of the one compiler they use, and code to that "standard"; so allowing different compilers or optimization levels to do different things when functions have side effects is just asking for surprises. In Python, the big speedups come from a change in algorithm. That's why it's imprtant to me that switch be dict-based (O(1)), as an alternative to an if/elif chain (O(N)). (The implementation doesn't have to use a regular dict, though; the important part is that it's based on hash() and __eq__().) -- --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