[Python-ideas] Assignment decorators (Re: The Descriptor Protocol...)

[Greg Ewing]

Raymond Hettinger wrote:

> We both agree about the virtues of readability and DRY. I just disagree 
> that either applies in the case of named tuples.

Named tuples aren't really the main motivation for me --
they're just something that it could be used with if you
wanted. The main use case for me is the overridable_property
descriptor that I described earlier.

There's a difference between them: with named tuples, the
name argument is really only for cosmetics -- if it doesn't
match the name it's bound to, nothing really bad happens.
The program still works; you just see a different name in
debug output, etc.

But with overridable_property, the name is an integral
part of the way it works, and it seems wrong to have to
leave it up to the user to get it right each and every
time he uses an overridable_property.

Imagine what it would be like if every class definition
you wrote had to look like this:

   class Fred('Fred'):
     ...

and furthermore, the code *wouldn't work* if the name passed
in was different from the name the class was bound to. You
complain about this, and keep getting told "It's not *that*
much of a problem, really -- you only have to write it once."
What would you think of that argument?

> The following seems weird to me and causes a mental hiccup when reading it:
> 
>   @namedtuple
>   Point = 'x y'

Yes, it seems weird to me, too, and I'm not really pushing
for it. I'd much rather see something like

   def fred = overridable_property("The fredness of the wongle")

[changing the example so we don't get too hung up on named
tuples.]

> The existing, Point = namedtuple('Point', 'x y') says what it does and 
> my eyes just breeze over it.  So, I don't see a readability win.
> 
> Also, I don't think the DRY principle applies.  ... you still end-up 
 > using the name over and over again.

But still, it involves being forced to write something more than once
when the repetition doesn't convey any extra information. That's
inefficient, whether you call it DRY or not.

> Another software engineering principle, the "Rule of Three" suggests 
> that the proposed abstraction doesn't meet the minimum threshold of 
> usefulness.

Hmmm, I need to google that one. Let's see...

Rule of three (writing) - Wikipedia, the free encyclopedia
The rule of three is a principle in writing that suggests that things that come 
in threes are inherently funnier, more satisfying, or more effective than ...

...er, no, not that one...

Rule of Three - Wikipedia, the free encyclopedia
Rule of three may refer to: Rule of three (medicine), for calculating a ...

...nope...

[tries again using "rule of three software engineering"]

...okay, here's something that looks relevant:

"Even if something appears to have all the requisite pattern elements, it should
not be considered a pattern until it has been verified to be a recurring
phenomenon (preferably in at least three existing systems -- this is often
called the rule of three)."
(from http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html)

So I guess what you're saying is that we need to find two more
use cases?

-- 
Greg