On Thu, 11 Oct 2007 13:04:53 +0000, Artur Siekielski wrote: > On Oct 11, 2:27 pm, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote: >> But why? Default getters and setters are unnecessary and if you need >> something other than the default you need to write it anyway more >> explicitly. > > I see some problems with your approach: > > 1. If I use instance field 'name' which is accessed directly by other > classes, > and later I decide to implement nonstandard getter, I must refactor > 'Person' class > and in some places change 'name' to '_name' (assuming this is now the > field's name). > The problem is that I cannot automatically change 'name' to '_name' > everywhere, because > in some places I want public property value (eg. validated and > formatted), and in other > places raw property value.
So what? Otherwise you carry *always* the baggage of a public property and a private attribute whether you need this or not. At least for me it would be unnecessary in most cases. > 2. Properties define (a part of) public interface of a class. When > using fields for public > access, you must tell this explicitly in documentation, or use name > convention. And public > fields definition is mixed with private fields, which doesn't happen > when using properties. Attributes are public unless you start the name with an underscore which is by convention a warning to not use that attribute unless you know what you are doing. With properties all over the place you use that convention anyway because the "real" value for `name` is bound as `_name`. So you clutter your API with two attributes for non-method-attributes. And a property is not automatically part of the public API, just if the name does not start with an underscore. > 3. Using properties as first-class objects gives possibilities to use > declarative approaches for constructing them. No idea what you mean here. Everything in Python is an object. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list