[Python-Dev] switch-based programming in Python

[M.-A. Lemburg]

"Martin v. Loewis" wrote:
> 
> > Now would such a change be acceptable if the optimization would
> > only be triggered for builtin immuatble types on both sides of
> > the "==" ?
> 
> It may be even acceptable with the language change if the procedures
> for introducing incompatible language changes are followed (i.e. add a
> __future__ import in one version, and only use the optimization if the
> future is imported; in the next version, decide that the future is
> there).

Perhaps we could approach other types in one of the next versions
(after 2.3). It possible I'd like to avoid creating new syntax.

I think having strings, unicode and numbers as first candidates
would already go a long way.
 
> When there is clearly no language change, the change would be
> acceptable to me if it would cause no "significant" slow-down if the
> optimization wasn't triggered. I assume you'll need a run-time test,
> so it is likely that there is atleast a small slow-down due to the
> additional test. Of course, only experiments can show whether the
> slow-down is "significant".

I'm sure we'll find some definition of "significant" which matches
these criteria ;-) 

Seriously, the optimization should only
be triggered for large enough if-elif-else constructs -- otherwise
it's likely that the dictionary lookup would take longer than the
sequential compares. By tuning the optimization trigger level
we can assure that the optimization will be a net win with
high probability.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/