[Python-Dev] towards a faster Python
Guido van Rossum
guido@python.org
Mon, 09 Jun 2003 20:30:19 -0400
> 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/)