[Python-3000] Set literals - another try
Guido van Rossum
guido at python.org
Wed Aug 9 20:43:50 CEST 2006
> On 8/9/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > A different way to enable that would be to include a set of non-keyword names
> > (a subset of the default builtin namespace) in the language definition that
> > the compiler is explicitly permitted to treat as constants if they are not
> > otherwise defined in the current lexical scope.
Right. This has been considered many times. I would love it if someone
wrote up a PEP for this.
On 8/9/06, Jim Jewett <jimjjewett at gmail.com> wrote:
> Realistically, I want my own functions and class definitions to be
> treated that way (inlinable) most of the time. I don't want to start
> marking them with "stable".
I'm not sure what you mean here. Inlining user code really isn't on
the table; it's unrealistic to expect this to happen any time soon
(especially since you're likely to want to inline things imported from
other modules too, and methds, etc.).
> > The only thing that would break is hacks like poking an alternate
> > implementation of str or set or len into the global namespace from somewhere
> > outside the module.
The PEP should consider this use case and propose a solution. I'm fine
with requiring a module to write
len = len
near the top to declare that it wants len patchable.
OTOH for open I think the compiler should *not* inline this as it is
fairly common to monkey-patch it.
> So what we need is a module that either rejects changes (after it is
> sealed) or at least provides notification (so things can be
> recompiled). In theory, this could even go into python 2.x (though
> not as the default), though it is a bit difficult in practice. (By
> the time you can specify an alternative dict factory, it is too late.)
Recompilation upon notification seems way over the top; it's not like
anything we currently do or are even considering.
I'd much rather pick one of the following:
(a) if the module doesn't have a global named 'len' and you add one
(e.g. by "m.len = ...") the behavior is undefined
(b) module objects actively reject attempts to inject new globals that
would shadow built-ins in the list that Nick proposes. (BTW having
such a list is a good idea. Requiring the compiler to know about *all*
built-ins is not realistic since some frameworks patch the __builtin__
PS. Nick, how's the book coming along?
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-3000