[Python-3000] Set literals - another try

[Guido van Rossum]

> 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__
module.)

PS. Nick, how's the book coming along?

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