[Python-Dev] towards a faster Python

[Guido van Rossum]

> Some builtins have names that are "obvious", such as "open". That makes them
> "obvious" names to want to use in other contexts. For example, I have a
> module mykindoffile and I want to be able to say mykindoffile.open('xxxx').
> 
> Imagine that mykindoffile is in Python; then mykindoffile.py might want to
> define open using an underlying extension:
> 
> import _mykindoffile
> open = _mykindoffile.open
> 
> Now imagine that mykindoffile is a package. I might have in
> mykindoffile/__init__.py something like:
> 
> from myopener import open
> 
> Now in all these cases I am setting an attribute in a module, but in a way
> that Python could detect when compiling mykindoffile. This is the kind of
> thing I do all the time.

None of these are affected by Neil's change.  Whenever a module
changes its *own* globals to shadow builtins, the parser can see the
change and can adjust its list of builtins that it can optimize.

> But there are, as noted, cases where Python cannot reasonably see what you
> are doing such as:
> mykindoffile.open = myopenf
> exec 'open=_mykindoffile.open' in mykindoffile 

Right.  Neil's patch warns about the first one; the second one is
dubious use (fortunately, to make it work, you'd actually have to
write 

  exec 'open=_mykindoffile.open' in mykindoffile.__dict__

which already signals "hack" to me.

If a module writes

  exec '...' in globals()

the parser can be warned, so this shouldn't be a problem.

> I feel that being able to use names like open is important, but it
> would be a rats nest to say that there were some ways you could do
> it and succeed, some that gave warning errors and might or might not
> fail, and some that could mysteriously fail without warning.

We should try to really minimize the latter kinds.  I think Neil's
patch is an important first step/

> Making a module dictionary readonly after importation would break
> legendary amounts of code.

And this won't ever happen.

> In fact, what I wish all the time is that a module was a kind of
> singleton class instance so that I could use properties,
> descriptors, etc. in it.

This won't ever happen either.  When you want a class, use one. :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)