> On 8/9/06, Nick Coghlan <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
