On Tue, 2004-04-20 at 17:21, Phillip J. Eby wrote:
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. :)
I'll grant you it's easier in a language like C#, but I don't think such code would be excessively complicated. The implementation needs a few levels of indirection, but not much more.
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 haven't read the text of PEP 267 in a quite a while ;-). At some point, we worked out a scheme that was completely backwards compatible. There are a couple of realistic options. One is to update the code at function definition time to insert the offsets for globals that are appropriate for the module. Another option is to initialize a table in the frame that is used for globals bindings.
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'm not opposed to that, but it isn't required to get good performance for globals.
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.)
I know how you feel, even though I've only got one PEP that I'm currently responsible for. Jeremy