RE: Does altering a private member decouple the property's value?
Thanks for the help! Using the class name (object) syntax fixed my problem. Usually, I don't need properties, but in the case of a dependent attribute, I used a set method of a property to update that dependent attribute. I have a stopwatch class with a time limit property. When the time limit is changed, the dependent attribute, remaining time, should also change. I am having to unteach myself some of the defensive programming techniques in C++, such as using name mangling to ensure privacy, when privacy is not the most important criterion. For prototyping, starting public and going private later is more efficient when refactoring. And since properties have the same access signature as a public member, it can be done without changes to the client. -- Ethan -- http://mail.python.org/mailman/listinfo/python-list
Re: Does altering a private member decouple the property's value?
Ethan Kennerly a écrit : Thanks for the help! Using the class name (object) syntax fixed my problem. (snip) I am having to unteach myself some of the defensive programming techniques in C++, such as using name mangling to ensure privacy, when privacy is not the most important criterion. For prototyping, starting public and going private later is more efficient when refactoring. (just a clarification for Python new-comers reading this thread) This is the usual way to handle public (non-callable) attributes - starting with a plain attribute, then refactoring to a property if and when needed. But this doesn't imply you should only use 'public' attributes. While it has no real notion of privacy (ie: no language-enforced access restriction), Python has a well-established convention for marking attributes and methods as protected : prefixing the name with a *single* underscore. This won't invoke any name-mangling nor prevent direct access to the attribute, but warn anyone that this attribute is implementation, IOW don't mess with it or you're on your own. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does altering a private member decouple the property's value?
Ben Finney a écrit : Ethan Kennerly [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does altering a private member decouple the property's value?
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... -- http://mail.python.org/mailman/listinfo/python-list
Re: Does altering a private member decouple the property's value?
Ethan Kennerly [EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Does altering a private member decouple the property's value?
On Tue, 19 Jun 2007 18:54:41 +1000, Ben Finney wrote: Ethan Kennerly [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does altering a private member decouple the property's value?
Ben Finney [EMAIL PROTECTED] wrote: Ethan Kennerly [EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Does altering a private member decouple the property's value?
Ethan Kennerly [EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Does altering a private member decouple the property's value?
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Does altering a private member decouple the property's value?
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 -- http://mail.python.org/mailman/listinfo/python-list
