New syntax for 'dynamic' attribute access

Thanks for the responses on this. In general: Guido van Rossum:
Greg Falcon:
Wow! I have to say this is a compelling idea.
Josiah Carlson:
My only concern with your propsed change is your draft implementation.
and on the syntax in particular: Guido van Rossum:
I've thought of the same syntax.
Greg Falcon:
The syntax is a bit foreign looking, but [...] I feel like I could learn to like it anyway.
Mostly positive, then, as far as the general idea and the syntax goes. On the two-argument form, Greg Falcon wrote:
I was definitely in two minds about whether the extension to the two-argument form was a win or a loss. It does increase the power of the new syntax, but it is certainly rather clumsy-looking. I'd be happy to prepare a patch with just the one-argument version if the consensus is that the balance is that way. Josiah Carlson:
I hadn't done so, no, but have now tried some tests. In fact, there is some evidence of a slight negative effect on the general performance. On my laptop, repeated pystone runs with 100,000 loops are quite variable but there might be a performance penalty of around 1% with the new code. I'm a bit puzzled by this because of course the new opcodes are never invoked in the pystone code --- does a switch statement become slower the more cases there are? (I tried grouping the cases with the new opcodes all together at the end of the switch, but the noisiness of the pystone results was such that I couldn't tell whether this helped.) Or is it just that the core bytecode-interpretation loop is bigger so has worse processor cache performance? On the other hand, getting/setting dynamic attributes seems to be about 40--45% faster with the new syntax, probably because you avoid the lookup of 'getattr' and the overhead of the function call. Anyway, I'll experiment with the other implementation suggestions made by Josiah, and in the meantime summarise the discussion so far to python-dev as suggested by Guido. Thanks, Ben.

Ben North <ben@redfrontdoor.org> wrote:
There have been a few examples where nontrivial blocks of code inserted into the mainloop of ceval.c slowed down Python. Indeed, it turns out that Python fit into the processor cache *just right*, and with much more, the cache was blown. Then again, 1% loss isn't really substantial, I wouldn't worry too much. Get a PEP number and talk to others in python-dev, put your patch up on sourceforge so that people on other platforms can test it out (and verify the 1% loss, if any), and if you are curious, then try out the idea I offered up - which has the potential to slow down *all* attribute lookups (though minimizes the source additions to the ceval.c mainloop).
That speedup sounds reasonable.
Great! I look forward to seeing this in Python 2.6 . - Josiah

On 2/11/07, Ben North <ben@redfrontdoor.org> wrote:
I wouldn't wait for the PEP number. The PEP editors, just like anyone else, can get busy. Go ahead and keep working on stuff. If you write a PEP, just fill the number with XXXs and say it is a draft or proto-PEP when you post it somewhere. Lots of people have written entire PEPs before getting a number so it is not unexpected. As Guido said, get something on python-dev for people to discuss, even if it is as simple as the syntactic proposal part. -Brett

Ben North <ben@redfrontdoor.org> wrote:
There have been a few examples where nontrivial blocks of code inserted into the mainloop of ceval.c slowed down Python. Indeed, it turns out that Python fit into the processor cache *just right*, and with much more, the cache was blown. Then again, 1% loss isn't really substantial, I wouldn't worry too much. Get a PEP number and talk to others in python-dev, put your patch up on sourceforge so that people on other platforms can test it out (and verify the 1% loss, if any), and if you are curious, then try out the idea I offered up - which has the potential to slow down *all* attribute lookups (though minimizes the source additions to the ceval.c mainloop).
That speedup sounds reasonable.
Great! I look forward to seeing this in Python 2.6 . - Josiah

On 2/11/07, Ben North <ben@redfrontdoor.org> wrote:
I wouldn't wait for the PEP number. The PEP editors, just like anyone else, can get busy. Go ahead and keep working on stuff. If you write a PEP, just fill the number with XXXs and say it is a draft or proto-PEP when you post it somewhere. Lots of people have written entire PEPs before getting a number so it is not unexpected. As Guido said, get something on python-dev for people to discuss, even if it is as simple as the syntactic proposal part. -Brett
participants (3)
-
Ben North
-
Brett Cannon
-
Josiah Carlson