[Python-Dev] PEP 318: Properties

[Jewett, Jim J]

>>Yes, this is a variation on the "Properties do not work for classic
>>classes, but you don't get a clear error when you try this." wart.
>>But the code this decorator replaces::

>>     x = property(getx, setx)

>>does explicitly replace x, so I think *this* confusion may be specific
>>to the decorator.

> Are you saying this is what you think, or what you think that newbies will

> think? 

I'm saying that it reads that way.  This does means that newbies will think
that, but it also means *I* will think that whenever I haven't *recently* 
read the docs or been burned.  It also means that when I'm debugging, I 
have to look more places to see why my value disappeared, just in case
someone used properties.

The reason to use a high-level language is that you can concentrate on your 
problem instead of worrying about implementation details.  Python normally
supports this very well.  It keeps most things explicit and it doesn't 
usually make you write much in the way of infrastructure/glue.  (Remember
the complaints about logging?  No one has suggested that it doesn't work 
well, only that it is too hard to use casually.)

What python does under the covers doesn't matter, *unless* the details
are so broken that I need to remember them.

	x=asdlfjk

looks like x is now set to something.  I expect it it to stay that way until
the next x=??? statement.  The fact that properties change it in a different
way under the covers doesn't matter; what matters is that it changes when
(and only when) I expect it to change.  By getting rid of the x=???
statement,
you force the programmer to keep more information in his own head.

> As for the implementation of propget and propset, if you look at Ed
Loper's 
> draft implementation, you'll see that an error is raised at function 
> definition time if there's an existing non-property binding for the named 
> function.

Which is an acceptable solution.  I would prefer that it keep the current
value, but I understand his objection that a particular getter might make 
"current value" meaningless.

What is not acceptable is a silent failure, planning to have it raise an
exception "sometime".  That would move the burden of implementation details 
back from the code that implements properties onto everyone who uses the
object.

-jJ