Skip Montanaro wrote:
>
> Just a few odd comments...
Thanks; I've added them to the next PEP revision.
>...
>
> mal> To prevent post-modifications of the jump-table dictionary
> mal> (which could be used to reach protected code), the jump-table
> mal> will have to be a read-only type (e.g. a read-only
> mal> dictionary).
> There was discussion once upon a time about adding a read-write flag to
> dictionaries to prevent modification during sensitive times. I gather lists
> already have such a flag to allow in-place sorting to work.
With the new subtyping mechanism I believe this should be easy
enough to implement as subtype. Could be useful in other cases too.
> ...
>
> mal> The compiler could then setup a read-only (perfect) hash
> mal> table, store it in the constants and add an opcode SWITCH
> mal> which triggers the following run-time behaviour:
> I think it would be sufficient to use a read-only dictionary. Perfect has
> tables are fine, but who wants to implement one?
You're probably right; the compiler could check for perfectness
though (e.g. the read-only dict could have a method or attribute
for testing this). If its not a perfect hash, there are several
possibilities of arranging for a perfect hash, e.g. double hashing,
slightly increasing the table size etc. I don't think its really
necessary to be picky about the perfectness unless non-perfect
hash tables are common for the current combination of Python
hash functions and dictionary implementation.
> mal> At runtime, SWITCH would check x for being one of the
> mal> well-known immutable types (strings, unicode, numbers) and
> mal> use the hash table for finding the right opcode snippet.
> And if one of the constraints isn't met, it would simply jump to the
> original if/elif/else code?
Right.
> ...
>
> mal> Issues:
>
> mal> There have been other proposals for the syntax which reuse
> mal> existing keywords and avoid adding two new ones ("switch" and
> mal> "case").
>
> Here's a wacky idea (probably wouldn't work syntactically, but hey, you
> never know):
>
> if EXPR:
> == CONSTANT:
> suite
> == CONSTANT:
> suite
> == CONSTANT:
> suite
> else:
> suite
>
> No new keywords, but I suspect the compiler would have to look too far ahead
> to realise that it's not compiling a regular if statement.
Naa... too weird looking :-)
> BTW, do you mean for your "suite"s to be optional?
No. We decided against fall-through ideas... I'll change them
to SUITE.
> Here are some
> concrete examples using each syntax variant
> ...
Thanks; I've added them to the PEP.
--
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company: http://www.egenix.com/
Python Software: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4