[Python-Dev] Summary: rejection of 'dynamic attribute' syntax (original) (raw)

Ben North ben at redfrontdoor.org
Wed Feb 14 14:04:14 CET 2007

Guido van Rossum wrote:

This seems to be the overwhelming feedback at this point, so I'm withdrawing my support for the proposal. I hope that Ben can write up a PEP and mark it rejected, to summarize the discussion; it's been a useful lesson.

The feedback is clear, yes. The "new syntax seems like overkill" camp has become dominant, and I certainly think these are very valid arguments. Gentle support remains scattered here and there, but the consensus has emerged. I will summarise all this into the PEP and mark it as rejected. Still, the discussion was useful, I thought. Thanks for the interest.

To respond, for the record, to some of the specific points recently raised:

glyph at divmod.com:

I really, really wish that every feature proposal for Python had to meet some burden of proof [...]. I suspect this would kill 90% of "hey wouldn't this syntax be neat" proposals on day zero [...]

This is what I understood the initial posting to python-ideas to be about. If the feedback from there had been "that's a stupid idea", then that would have been the end of it. I think it's a good thing that there's the python-ideas mechanism for speculative suggestions.

I like the "attrview" or "attrs" wrapper idea, with the example given by Larry Hastings:

setattr(self, methodname, getattr(self.metadata, methodname)) [...] would be: attrview(self)[methodname] = attrview(self.metadata)[methodname]

As others point out, it's very clean, captures the intended uses well, and has the great advantage of having easily-added backwards compatibility. I might start using it :-) If the people who suggested and refined this were to put it in a PEP, I'd be in favour.

Guido van Rossum wrote:

I missed discussion of the source of the 1%. Does it slow down pystone or other benchmarks by 1%? That would be really odd, since I can't imagine that the code path changes in any way for code that doesn't use the feature. Is it that the ceval main loop slows down by having two more cases?

That seems to be it, yes. I tested this by leaving the grammar, compilation, and AST changes in, and conditionally compiling just the three extra cases in the ceval main loop. Measurements were noisy though, as Josiah Carlson has also experienced:

I've found variations of up to 3% in benchark times that seemed to be based on whether I was drinking juice or eating a scone while working.

I'm afraid I can't remember what I was eating or drinking at the time I did my tests.

(Thanks also for the kind words regarding my summaries etc. Having caused all the fuss in the first place I felt obliged to try to make myself a bit useful :-)

Ben.

More information about the Python-Dev mailing list