Raymond Hettinger wrote:
>>> The optimisation of the if-elif case would then simply be to say that the
>>> compiler can recognise if-elif chains like the one above where the RHS
>>> of the comparisons are all hashable literals and collapse them to switch
>>> statements.
>>>
>>
>> Right (constants are usually hashable :-).
>>
>
> The LHS is more challenging. Given:
>
> if x == 1: p_one()
> elif x == 2: p_two()
> elif x == 3: p_three()
> else: p_catchall()
>
> There is no guarantee that x is hashable. For example:
>
> class X:
> def __init__(self, value):
> self.value = value
> def __cmp__(self, y):
> return self.value == y
> x = X(2)
That's a good point.
The PEP already addresses this by retricting the type of x to a
few builtin immutable and hashable types:
...the switching variable is one of the builtin
immutable types: int, float, string, unicode, etc. (not
subtypes, since it's not clear whether these are still
immutable or not).
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jun 16 2006)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
_______________________________________________
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
