On 6/26/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: > On Mon, 26 Jun 2006, Guido van Rossum wrote: > > I've written a new PEP, summarizing (my reaction to) the recent > > discussion on adding a switch statement. While I have my preferences, > > I'm trying to do various alternatives justice in the descriptions. > > Thanks for writing this up! > > The section that most draws my attention is "Semantics", and i guess > it isn't a surprise to either of us that you had the most to say > from the perspective you currently support (School II). :) Let me > suggest a couple of points to add: > > - School I sees trouble in the approach of pre-freezing a dispatch > dictionary because it places a new and unusual burden on the > programmer to understand exactly what kinds of case values are > allowed to be frozen and when the case values will be frozen.
Can you please edit the PEP yourself to add this? That will be most efficient. > - In the School II paragraph you say "Worse, the hash function > might have a bug or a side effect; if we generate code that > believes the hash, a buggy hash might generate an incorrect > match" -- but that is primarily a criticism of the School II > approach, not of the School I approach as you have framed it. > It's School II that mandates that the hash be the truth. You seem to misunderstand what I'm saying or proposing here; admittedly I think I left something out. With school I, if you want to optimize using a hash table (as in PEP 275 Solution 1) you have to catch and discard exceptions in hash(), and a bug in hash() can still lead this optimization astray: if A == B but hash(A) != hash(B), "switch A: // case B: ... // else: ..." may falsely take the else branch, thereby causing a hard-to-debug difference between optimized and unoptimized code. With school II, exceptions in hash() aren't caught or discarded; a bug in hash() leads to the same behavior as optimized school I, but the bug is not dependent on the optimization level. > (It looks to me like what you're actually criticizing here is > based on some assumptions about how you think School I might > be implemented, and having taken School I a number of steps > down that (unexplained) road you then see problems with it.) Right. School I appears just as keen as school II to use hashing to optimize things, but isn't prepared to pay the price in semantics; but I believe the optimizations are impossible to behave completely identically to the unoptimized code (not even counting side effects in hash() or __eq__()) so I believe the position that the optimized version is equivalent to the unoptimized "official semantics" according to school I is untenable. > Also, why is the discussion of School II mostly an argument against > School I? What about describing the advantages of each school? School II has the advantage of not incurring the problems I see with school I, in particular catching and discarding exceptions in hash() and differences between optimized and unoptimized code. -- --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