[Python-Dev] Re: [Python-checkins] python/nondist/peps pep-0329.txt, 1.2, 1.3

[Phillip J. Eby]

At 04:50 PM 4/20/04 -0400, Jeremy Hylton wrote:
>On Tue, 2004-04-20 at 12:16, Phillip J. Eby wrote:
> > Would this be acceptable?  It seems to me that this approach would allow
> > Jython and IronPython the option in future of replacing lookups of 
> builtins
> > with static field accesses and/or method calls, which would give them 
> quite
> > a potential performance boost.
>
>This is basically what IronPython does already.  A sufficiently clever
>implementation can make the current semantics go fast enough.

Actually, I suspect the cleverness of implementation required is what has 
kept anybody from actually implementing it for CPython at least.  :)


>   Thus,
>we'd only need changes to the compiler, not even changes to the
>language.  This is the most attractive option to me (see PEP 267).

PEP 267 isn't backwards compatible either, since it requires that "Each 
code object would then be bound irrevocably to the module it was defined 
in."  (And yes, there are lots of not-so-subtle problems with this, such as 
'exec codeobject in dict'.)

I think it would be helpful for the language spec to include the rules for 
potential optimizing of built-ins, and cover what happens if you attempt to 
replace a builtin whose dynamic nature has been optimized away.


>I don't like the PEP 329 approach because it adds extra complexity to
>each module to work around a limitation of the current implementation
>that will almost surely disappear one day.

Agreed.  The thing I'm proposing really needs another PEP.  Unfortunately, 
I need authorship or co-authorship of *another* PEP like I need another 
hole in my head.  :)  (I've been asked to help w/246 and 318 already, and 
have had a web container API pre-PEP on the back burner for a few months now.)