On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > On 6/26/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > I like Python's rules to be simple, and I > > prefer to occasionally close off a potential optimization path in the > > sake of simplicity. > > (Almost) everyone agrees that the case expressions SHOULD be run-time > constants. The disagreements are largely over what to do when this > gets violated.
Thanks for the elaboration. I'm not sure how to respond except to correct your representation of my position: > Bad Case Option (1) -- Accept everything > ---------------------------------------- > > Readability is everything. Switch/case tells you that every branch is > using similar predicates on the same variable. If that variable or > predicate can't be easily optimized, then so what -- it is still > better to read. (Largely School Ia) > > > Bad Case Option (2) -- Accept very little > ----------------------------------------- > > Enforce good case expressions. (Raymond's proposal) This does the > right thing when it works, but it is initially very restricted -- and > a crippled case statement may be worse than none at all. > > > Bad Case Option (3) -- Raise Exceptions > --------------------------------------- > > Flag bugs early. The semantics require non-overlapping hashable > constants, so raise an exception if this gets violated. This does the > right thing, but catching all the violations in a timely manner is > hard. > > Freezing at first use is too late for a good exception, but any > earlier has surprising restrictions. > > There is no good way to realize that a "constant" has changed after the > freeze. > > > Bad Case Option (4) -- Ignore problems > -------------------------------------- > > This is for optimization; go ahead and ignore any problems you can. > Maybe that branch will never be taken... Ironically, this is also > largely school I, since it matches the if semantics. > > > Bad Case Option (5) -- ad hoc mixture > ------------------------------------- > > Pick an arbitrary set of rules, and follow it. > > Guido is currently leaning towards this, with the rules being "freeze > at definition", raise for unhashable, ignore later changes, undecided > on overlapping ranges. Actually I'm all for flagging overlapping changes as errors when the dict is frozen. > The disadvantage is that people can "cheat" with non-constant > expressions. Sometimes, this will work out great. Sometimes it will > lead to nasty non-localized bugs. We have to explain exactly which > cheats are allowed, and that explanation could get byzantine. Actually I would simply explain that all cheats are frowned upon, just like all side effects in case expressions. > > > Bad Case Option (6) -- Undefined > -------------------------------- > > Undefined behavior. We don't yet know which strategy (or mix of > strategies) is best. So don't lock ourselves (and Jython, and PyPy, > and IronPython, and ShedSkin, and ...) into the wrong strategy. > > The down side is that people may start to count on the actual behavior > anyhow; then (in practice) we might just have Bad Case Option (5) > without documentation. > > -jJ > -- --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
