At 09:07 PM 4/4/04 -0400, Jewett, Jim J wrote:
>Not really. The documentation says
>
> "Properties are a neat way to implement attributes whose usage
> resembles attribute access, but whose implementation uses method
> calls."
>
>This suggests that creating a property creates a manager. In this case,
>the manager is created for an attribute that already exists. If it uses
>the previous value as the initial current value, that is what I expect.
>If it raises an exception ("I can't manage that! Someone beat me to it!"),
>I'll be annoyed, but live with the limitation. If it silently throws the
>value away, or raises an exception at run time -- that is bad.
>
>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? If this is what you think, you probably need to read the descriptor
tutorial (and perhaps PEP 252) again. Descriptors don't work anything like
what you're talking about.
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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4