Thomas Wouters wrote:
>
> On Thu, Nov 08, 2001 at 12:32:39PM +0100, M.-A. Lemburg wrote:
> > Thomas Wouters wrote:
>
> > > Would a lengthy if/elif/elif/else construct work better ? Why ?
>
> > Yes, because it doesn't involve calling methods, no execution
> > frames have to be setup, no arguments need to be passed in,
> > state can be managed in local variables, etc.
>
> > > I'm not sure what you want the if/else to actually do. Personally, I
> > > either need a function call in there (in which case a dispatch table calling
> > > the function directly, sometimes with apply() or lambda-wrapper tricks, does
> > > fine) or some kind of variable assignment, in which case a simple dict
> > > lookup works just as fine. Then again, I don't write that much Python code.
>
> > You don't ?
>
> Is that sarcasm ? :) No, I don't. My actual job, the part I get paid for,
> doesn't (yet) involve writing Python. It's part C and Perl, part system
> design, and part administration. So Python is just a hobby.
You should change that ;-)
BTW, how did you get XS4ALL into funding the www.python.org traffic,
if they don't heavily depend on Python ?
> > > I personally wouldn't be adverse to a switch-like syntax, as long as we
> > > define it like a dict dispatch (the argument is evaluated once, it should be
> > > hashable, and all the 'cases' should be hashable -- preferably even
> > > compile-time constants.) I like the idea, I'm just not sure if there's
> > > enough use for it.
>
> > That's the idea.
>
> > There's enough need in it for my applications, so I'd go through
> > the trouble of writing the code for it, provided I get the OK
> > and help from python-dev.
>
> The writing part would be very tricky. I don't think you can do it without
> syntax support, at least not reliably, even if 'without syntax support' is
> some kind of directive statement to signal that a particulare
> if/elif/elif/else chain should be converted to a jump table behind the
> scene.
Well, I tried to avoid syntax changes for two reasons:
1. new keywords are a problem (even though I like your proposed syntax
very much)
2. old code should be able to benefit from the new feature
I think that Skip's proposal would go a long way (sketching here
a bit):
It should be possible for the compiler to detect an if-elif-else
construct which has the following signature:
if x == 'first':...
elif x == 'second':...
else:...
(ie. LHS always the same variable, RHS some hashable immutable
builtin type)
The compiler could then setup a perfect hash table, store it
in the constants and add some opcode which triggers the following
run-time behaviour:
At runtime, the interpreter would check x for being one of the
well-known immutable types (strings, unicode, numbers) and
use the hash table for finding the right opcode snippet.
> For new syntax, I'd imagine something like this:
>
> switch EXPR:
> case CONSTANT:
> [suite]
> case CONSTANT:
> [suite]
> ...
> else:
>
> EXPR is a normal Python expression. CONSTANT should be a hashable constant
> (with a persistant hash value, duh) so we don't have to re-hash all the
> cases when entering the switch. The 'else' would function like a 'default:'
> case in C's switch. I'm not sure on the naming of 'switch' and 'case', nor
> about the indentation-level of the 'cases'. And what to do about
> fallthrough? It's commonly accepted (or at least argued :) as a design flaw
> that C's switch() defaults to fallthrough. Bytecodewise it should probably
> turn something like:
I think you missed some indents in your example. I added them again,
removing the parens around x and tweaked the formatting a bit (also
note the addition of a few breaks).
def whatis(x):
switch x:
case 'one':
print '1'
break
case 'two':
print '2'
# fall through
case 'three':
print '3'
break
else:
print "D'oh!"
Turns out that this look very Pythonic :-)
> Into (ommitting POP_TOP's and SET_LINENO's):
>
> 6 LOAD_FAST 0 (x)
> 9 LOAD_CONST 1 (switch-table-1)
> 12 SWITCH 26 (to 38) # or maybe 'SWITCH <table-index>'
>
> 14 LOAD_CONST 2 ('1')
> 17 PRINT_ITEM
> 18 PRINT_NEWLINE
> 19 JUMP 43
>
> 22 LOAD_CONST 3 ('2')
> 25 PRINT_ITEM
> 26 PRINT_NEWLINE
> 27 JUMP 43
>
> 30 LOAD_CONST 4 ('3')
> 33 PRINT_ITEM
> 34 PRINT_NEWLINE
> 35 JUMP 43
>
> 38 LOAD_CONST 5 ("D'oh!")
> 41 PRINT_ITEM
> 42 PRINT_NEWLINE
>
> >>43 LOAD_CONST 0 (None)
> 46 RETURN_VALUE
>
> Where the 'SWITCH' opcode would jump to 14, 22, 30 or 38 depending on 'x'.
> PEP, anyone ? :)
Sure smells like PEP-time :-)
If I get some more positive feedback on this, I'll start
looking into this.
--
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