[Python-3000] Set literals - another try (original) (raw)

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

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

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

More information about the Python-3000 mailing list