[Python-Dev] Summary: rejection of 'dynamic attribute' syntax

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

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, method_name, getattr(self.metadata, method_name))
> [...] would be:
>     attrview(self)[method_name] = attrview(self.metadata)[method_name]

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 :-)


More information about the Python-Dev mailing list