[Python-Dev] towards a faster Python

[M.-A. Lemburg]

Guido van Rossum wrote:
>>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.
> 
> 
> I'm not sure what you mean by "extending builtins", but if it is what
> I think it is, I am strongly opposed.  The builtins should have fixed
> capabilities (in a particular Python version).  If you want a function
> that behaves just like a builtin but also can do something else, give
> it a different name and import it explicitly, don't override the
> existing entry in __builtin__.  If you have a new function that you
> want to use in lots of code, resist the temptation to add it to the
> __builtin__ module.  Zope did this e.g. with get_transaction() and the
> net result was reader confusion and intractable dependencies on import
> order.

I am talking about what mxTools is doing: adding new builtins to
the interpreter by placing them into the __builtins__ dictionary.
While I agree that it is usually better to use something like
'from x import *' or even naming the tools explicitly, some features
in mxTools do warrant being made builtins, e.g. irange() has been
most helpful in the past :-)

Note that I'm not talking about overriding existing builtins. mxTools
just adds a few more (that's what I meant with "extending builtins").

>>2. What happens if a new Python version introduces new builtins
>>    that are in use by some modules out there for other purposes ?
> 
> *** THIS IS NOT AFFECTED! ***
> 
> There is no proposal on the table to ban the use of identifiers known
> to be built-ins for any purpose.  If a module defines a class,
> function or variable that shadows a builtin name, that's fine, because
> the parser has no problem detecting this situation.
> 
> The *only* thing being banned is insertion of a new name that shadows
> a builtin from outside a module.
> 
> IOW:
> 
>   # module foo
>   def open(): return ...
> 
> is fine, but
> 
>   import foo
>   foo.open = 42
> 
> is not.

I presume you mean the case that foo.open is not already defined in
foo. That's good.

-- 
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