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

[glyph at divmod.com]

On 01:04 pm, ben at redfrontdoor.org wrote:

>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.

Discussion, with any audience, no matter how discerning, isn't really going to be a useful filter unless the standards of that audience are clear.

What I was trying to say there is that the proposal of new ideas should not begin with "Hey, I think this might be 'good'" - that's too ill defined.  It should be, "I noticed (myself/my users/my students/other open source projects) writing lots of code that looks like *this*, and I think it would be a real savings if it could look like *that*, instead".  Some back-of-the-envelope math might be nice, in terms of savings of lines of code, or an explanation of the new functionality that might be enabled by a feature.

More than the way proposals should work, I'm suggesting that the standards of the community in _evaluating_ to the proposals should be clearer.  The cost-benefit analysis should be done in terms of programmer time, or ease of learning, or  integration possibilities, or something.  It doesn't *necessarily* have to be in terms of "lines of code saved", but especially for syntax proposals, that is probably a necessary start.  It's fine to have some aesthetic considerations, but there's a lot more to Python than aesthetics, and right now it seems like the majority of posts coming into threads like this one are "I don't like the proposed ':==|', it's ugly.  How about '?!?+' instead?"

The short version of this is that any feature should describe what task it makes easier, for whom, and by how much.  This description should be done up front, so that the discussion can center around whether than analysis is correct and whether it is worth the ever-present tradeoff against upgrade headaches.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070214/20e1528f/attachment.htm