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. 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. 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. 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 _______________________________________________ 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
