Does altering a private member decouple the property's value?

Discussion in 'Python' started by Ethan Kennerly, Jun 19, 2007.

  1. Hello,

    There are a lot of Python mailing lists. I hope this is an appropriate one
    for a question on properties.

    I am relatively inexperienced user of Python. I came to it to prototype
    concepts for videogames. Having programmed in C, scripted in Unix shells,
    and scripted in a number of proprietary game scripting languages, I'm
    impressed at how well Python meets my needs. In almost all respects, it
    does what I've been wishing a language would do.

    One example is properties. I really like properties for readonly
    attributes, and their ability to make the interface more elegant, by hiding
    uninteresting methods (like dumb get/set accessors). As a user interface
    designer, I respect how this may prevent the programmer's deluge of
    unimportant information. I also value the ease of refactoring, which is a
    frequent task in my prototypes.

    But a gotcha bit me in the behavior of properties that I didn't expect.
    If another function accesses an underlying data member of a property, then
    the data member returned by the property is no longer valid.

    Here is a session example.

    PythonWin 2.4.3 - Enthought Edition 1.0.0 (#69, Aug 2 2006, 12:09:59) [MSC
    v.1310 32 bit (Intel)] on win32.
    Portions Copyright 1994-2004 Mark Hammond () - see
    'Help/About PythonWin' for further copyright information.

    >>> class a_class:

    .... def __init__( self ): self.__p = None
    .... def __set_p( self, new_p ): self.__p = new_p
    .... def reset( self ): self.__p = None
    .... p = property( lambda self: self.__p, __set_p )
    ....
    >>> a = a_class()
    >>> a.p
    >>> a.p = 1
    >>> a.p

    1
    >>> a.reset()
    >>> a.p

    1

    Although the underlying value was reset, the property was not reset!

    Instead, if the property is edited, then all is fine.

    >>> class a_class:

    .... def __init__( self ): self.__p = None
    .... def __set_p( self, new_p ): self.__p = new_p
    .... def reset( self ): self.p = None # Property, not the private
    member
    .... p = property( lambda self: self.__p, __set_p )
    ....
    >>> a = a_class()
    >>> a.p
    >>> a.p = 1
    >>> a.reset()
    >>> a.p


    I had wanted to access the private data member in the class to avoid
    side-effects of the set method.

    Can someone show me how to reference the data member underlying a property
    and update the property without calling the property set method?

    By the way, I thought maybe that a variable outside of an __init__ method
    would be static, but as far as I can tell, it is dynamic. For example, the
    following class appeared equivalent to the above for tests.

    >>> class a_class:

    .... __p = None # No __init__
    .... def __set_p( self, new_p ): self.__p = new_p
    .... def reset( self ): self.p = None
    .... p = property( lambda self: self.__p, __set_p )
    ....
    >>> a = a_class()
    >>> a.p
    >>> a.p = 1
    >>> a.reset()
    >>> a.p
    >>>


    I preferred not having the __init__ for this example and my prototype,
    because I wasn't doing anything fancy, and it meant one less method that the
    programmer needed to see. Again, the interface is cleaner. But does this
    cause an error for derived classes that would use the private data member?
    Without the __init__ method, is the derived class' __p equal to the base
    class' __p?

    I thought maybe the class was being referenced instead of the instance, but
    a second object had a different value.

    >>> b = a_class()
    >>> b.p
    >>> b.p = 2
    >>> b.p

    2
    >>> b.reset()
    >>> a.p
    >>> a.p = 1
    >>> a.p

    1
    >>> b.p
    >>> b.p = 2
    >>> b.reset()
    >>> a.p

    1
    >>> b.p
    >>>


    Also properties don't show up in the dictionary if no assignment has been
    made, but once a property's assignment has been called, the property
    appears. An example follows:

    >>> import pprint
    >>> pprint.pprint( a.__dict__ )

    {'p': 1}
    >>> pprint.pprint( b.__dict__ )

    {'p': None}
    >>> c = a_class()
    >>> pprint.pprint( c.__dict__ )

    {}
    >>> c.p
    >>> pprint.pprint( c.__dict__ )

    {}

    Is that dictionary population behavior for detecting an uninitialized
    property?

    Thanks for your help. When my feet are properly wet, I look forward to
    contributing to the community.

    -- Ethan Kennerly
    Ethan Kennerly, Jun 19, 2007
    #1
    1. Advertising

  2. Ethan Kennerly <> wrote:
    ...
    > There are a lot of Python mailing lists. I hope this is an appropriate one
    > for a question on properties.


    yep, it's a fine one.

    > But a gotcha bit me in the behavior of properties that I didn't expect.
    > If another function accesses an underlying data member of a property, then
    > the data member returned by the property is no longer valid.


    You're interpreting wrongly the symptoms you're observing.

    > >>> class a_class:


    This is ALL of the problem: you're using a legacy (old-style) class, and
    properties (particularly setters) don't work right on its instances (and
    cannot, for backwards compatibility: legacy classes exist exclusively to
    keep backwards compatibility with Python code written many, many years
    ago and should be avoided in new code).

    Change that one line to

    class a_class(object):

    and everything else should be fine. If you want, I can try to explain
    the why's and wherefore's of the problem, but to understand it requires
    deeper knowledge of Python than you'll need for just about any practical
    use of it: just retain the tidbit "NEVER use oldstyle classes" and you
    won't need to understand WHY you shouldn't use them:).


    Alex
    Alex Martelli, Jun 19, 2007
    #2
    1. Advertising

  3. Ethan Kennerly

    Jay Loden Guest

    Alex Martelli wrote:
    >
    >>>>> class a_class:

    >
    > This is ALL of the problem: you're using a legacy (old-style) class, and
    > properties (particularly setters) don't work right on its instances (and
    > cannot, for backwards compatibility: legacy classes exist exclusively to
    > keep backwards compatibility with Python code written many, many years
    > ago and should be avoided in new code).
    >
    > Change that one line to
    >
    > class a_class(object):
    >
    > and everything else should be fine. If you want, I can try to explain
    > the why's and wherefore's of the problem, but to understand it requires
    > deeper knowledge of Python than you'll need for just about any practical
    > use of it: just retain the tidbit "NEVER use oldstyle classes" and you
    > won't need to understand WHY you shouldn't use them:).


    Can you elaborate (or just point me to a good doc) on what you mean by an "old style" class versus the new style? I learned Python (well, am still learning) from an older book, and I just want to make sure that I'm using the preferred method.

    Thanks,

    -Jay
    Jay Loden, Jun 19, 2007
    #3
  4. Ethan Kennerly

    Jay Loden Guest

    Jay Loden wrote:
    > Can you elaborate (or just point me to a good doc) on what
    > you mean by an "old style" class versus the new style? I
    > learned Python (well, am still learning) from an older book,
    > and I just want to make sure that I'm using the preferred method.


    Answering my own question, I know, but Google and the right keywords is a wonderful thing. In case anyone else is interested:

    http://www.python.org/doc/newstyle.html

    -Jay
    Jay Loden, Jun 19, 2007
    #4
  5. Ethan Kennerly

    Ben Finney Guest

    "Ethan Kennerly" <> writes:

    > I really like properties for readonly attributes,


    Python doesn't have "readonly attributes", and to attempt to use
    properties for that purpose will only lead to confusion.

    > and their ability to make the interface more elegant, by hiding
    > uninteresting methods (like dumb get/set accessors).


    The best solution to this is not to create get/set accessors at
    all. Just define a simple data attribute, name the attribute
    logically, and use it normally. When the interface demands something
    other than a plain attribute, *then* consider changing it to a
    property; but prefer a plain data attribute in the usual case.

    > >>> class a_class:


    Define your classes as inheriting from 'object', or some other type in
    the Python type hierarchy, and properties will work as expected.

    class a_class(object):
    # foo

    --
    \ "When I get real bored, I like to drive downtown and get a |
    `\ great parking spot, then sit in my car and count how many |
    _o__) people ask me if I'm leaving." -- Steven Wright |
    Ben Finney
    Ben Finney, Jun 19, 2007
    #5
  6. Ben Finney <> wrote:

    > "Ethan Kennerly" <> writes:
    >
    > > I really like properties for readonly attributes,

    >
    > Python doesn't have "readonly attributes",


    Many Python types do, e.g.:

    >>> def f(): pass

    ....
    >>> def g(): pass

    ....
    >>> f.func_name = 'zap'
    >>> f.func_code = g.func_code
    >>> f

    <function zap at 0x66070>
    >>> f.func_code

    <code object g at 0x55458, file "<stdin>", line 1>
    >>> f.func_closure = g.func_closure

    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    TypeError: readonly attribute

    i.e., you can reassign some of f's attributes (such as its name and
    code) but others (such as its closure) are readonly (as the TypeError's
    message says) so you cannot reassign those.

    It makes just as much sense for user-coded types (aka classes) to have
    some r/w attributes and others that are readonly, as it does for builtin
    types -- and properties are often the simplest way to accomplish that.

    > and to attempt to use
    > properties for that purpose will only lead to confusion.


    I disagree -- a property is a great way to implement readonly
    attributes, as long as you're using a new-style class of course.


    class Rectangle(object):

    def __init__(self, w, h):
    self.w = w
    self.h = h

    area = property(lambda self: self.w * self.h)

    No confusion here -- given a Rectangle instance r, you can both read and
    write (reassign) r.w and r.h, but r.area is readonly (can't be set):

    >>> r = Rectangle(12, 34)
    >>> r.area

    408
    >>> r.h = 10
    >>> r.area

    120
    >>> r.area = 144

    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    AttributeError: can't set attribute


    Alex
    Alex Martelli, Jun 19, 2007
    #6
  7. On Tue, 19 Jun 2007 18:54:41 +1000, Ben Finney wrote:

    > "Ethan Kennerly" <> writes:
    >
    >> I really like properties for readonly attributes,

    >
    > Python doesn't have "readonly attributes", and to attempt to use
    > properties for that purpose will only lead to confusion.



    class Parrot(object):
    def _plumage(self):
    return "Beautiful red plumage"
    plumage = property(_plumage)


    >>> parrot = Parrot()
    >>> parrot.plumage

    'Beautiful red plumage'
    >>> parrot.plumage = "Ragged grey feathers"

    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    AttributeError: can't set attribute

    It walks like a read-only attribute, it squawks like a read-only
    attribute, but since Python doesn't have read-only attributes, Ben must be
    right: using properties to implement read-only attributes will only lead
    to confusion.

    *wink*


    --
    Steven.
    Steven D'Aprano, Jun 19, 2007
    #7
  8. Ben Finney a écrit :
    > "Ethan Kennerly" <> writes:
    >
    >> I really like properties for readonly attributes,

    >
    > Python doesn't have "readonly attributes",


    Err... Ever tried to set a class mro ?-)

    > and to attempt to use
    > properties for that purpose will only lead to confusion.


    read-only attributes actually are one of the common use-case for properties.
    Bruno Desthuilliers, Jun 20, 2007
    #8
  9. Ethan Kennerly a écrit :
    > Hello,
    >
    > There are a lot of Python mailing lists. I hope this is an appropriate one
    > for a question on properties.


    It is.

    > I am relatively inexperienced user of Python. I came to it to prototype
    > concepts for videogames. Having programmed in C, scripted in Unix shells,
    > and scripted in a number of proprietary game scripting languages, I'm
    > impressed at how well Python meets my needs. In almost all respects, it
    > does what I've been wishing a language would do.


    So welcome onboard !-)

    > One example is properties. I really like properties for readonly
    > attributes, and their ability to make the interface more elegant, by hiding
    > uninteresting methods (like dumb get/set accessors).


    FWIW, since Python has properties, you often just don't need the
    getter/setter pairs. Start with a plain publi attribute, then switch to
    a computed one (using property or a custom descriptor) if and when needed.

    >
    > But a gotcha bit me in the behavior of properties that I didn't expect.
    > If another function accesses an underlying data member of a property, then
    > the data member returned by the property is no longer valid.
    >
    > Here is a session example.
    >


    >>>> class a_class:


    oops ! properties don't work properly with old-style classes. Use a
    new-style class instead:

    class AClass(object):

    > ... def __init__( self ): self.__p = None
    > ... def __set_p( self, new_p ): self.__p = new_p


    Take care, the name mangling invoked by the '__name' scheme may lead to
    undesired results. This feature should only be used when you want to
    make sure an attribute will not be accidentally used in a derived class.
    The idiomatic way to mark an attribute as "implementation" is a single
    leading underscore, ie: '_name'.

    > ... def reset( self ): self.__p = None
    > ... p = property( lambda self: self.__p, __set_p )
    > ...


    (snip)

    >
    > I had wanted to access the private data member in the class to avoid
    > side-effects of the set method.
    >
    > Can someone show me how to reference the data member underlying a property
    > and update the property without calling the property set method?


    cf above.

    While we're at it, everything in Python being an object - yes, functions
    and methods too -, and there's nothing like a "private" modifier in
    Python. So s/private data member/implementation attribute/ !-)


    > By the way, I thought maybe that a variable outside of an __init__ method
    > would be static,


    An attribute defined in the class body (ie not in a method) becomes a
    class attribute (shared by all instances).

    > but as far as I can tell, it is dynamic. For example, the
    > following class appeared equivalent to the above for tests.
    >
    >>>> class a_class:

    > ... __p = None # No __init__


    here, you create a class attribute

    > ... def __set_p( self, new_p ): self.__p = new_p


    And here, you create an instance attribute that will shadow the class
    attribute.

    >
    > I preferred not having the __init__ for this example and my prototype,
    > because I wasn't doing anything fancy, and it meant one less method that the
    > programmer needed to see.


    There are other ways to obtain the same result. Like defining the
    __new__ method (the proper constructor).

    (snip the rest)

    I think you should take some time to learn the Python object model -
    trying to apply C++/Java concepts to Python won't do it. Articles about
    new-style classes and descriptors on python.org should be a good
    starting point.

    My 2 cents...
    Bruno Desthuilliers, Jun 20, 2007
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Peng Yu
    Replies:
    3
    Views:
    1,067
    Simon Forman
    Sep 21, 2009
  2. Dirk Nachbar

    decouple copy of a list

    Dirk Nachbar, Dec 10, 2010, in forum: Python
    Replies:
    9
    Views:
    198
    Jean-Michel Pichavant
    Dec 10, 2010
  3. ittium
    Replies:
    5
    Views:
    429
    88888 Dihedral
    Jan 12, 2012
  4. Rie!
    Replies:
    3
    Views:
    120
  5. epaetz

    decouple parent window from children

    epaetz, Jul 19, 2006, in forum: Javascript
    Replies:
    2
    Views:
    92
    epaetz
    Jul 24, 2006
Loading...

Share This Page