[Python-Dev] towards a faster Python

[M.-A. Lemburg]

Neil Schemenauer wrote:
> The goal is that the compiler should be able to determine the scope of a
> name at compile time.  Code like the above does not allow that and so
> non-local names must be searched for in both globals and builtins at run
> time.  Unfortunately the warning is not bulletproof.  It's possible to
> modify the module dict directly and bypass the warning.  I'm not sure
> what to do about that. :-(
 >
> Eventually we might want to allow optimizations based on known builtin
> functions.  For example, code like
> 
>     for i in range(100000):
>         ...
> 
> could be rewritten to use an integer counter rather than creating a list
> and then iterating over it.  I'm not sure how much resistance there
> would be in the community to disallowing reassignment of builtin names
> though.  I don't think I've ever reassigned a builtin name so I think it
> would be worth it.

All very nice, but you'll have to think about two cases which
could cause trouble:

1. Extending builtins should still be possible like it is now.

    Of course, the extensions wouldn't take part in the optimizations
    you have in mind, but they should still be found.

2. What happens if a new Python version introduces new builtins
    that are in use by some modules out there for other purposes ?

    The problem here is similar to that of introducing new keywords.
    Modules should still be able to override builtin names in their
    globals; directly, via the global statement and also dynamically
    (modules are often used as container for global variables and
    state).

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Software directly from the Source  (#1, Jun 10 2003)
 >>> Python/Zope Products & Consulting ...         http://www.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
EuroPython 2003, Charleroi, Belgium:                        14 days left