bruno.42.desthuilliers at wtf.websiteburo.oops.com
Thu Oct 11 19:08:37 CEST 2007
Artur Siekielski a écrit :
> On Oct 11, 4:21 pm, "sjdevn... at yahoo.com" <sjdevn... at yahoo.com> wrote:
>> In practice, it turns out to be a lot less work to deal with that
>> occasionally than to always deal with lugging around internal
>> attributes and external properties when they're really not needed. By
>> writing everything as properties up front you're just creating more
>> work for yourself, and it's generally considered bad practice in
>> Python to have default getters/setters (whether part of a property or
> Ok, I appreciate your and Marc's argument. So I see that a pythonic
> way is
> using public attributes, and it works in real life.
> "generation" of
> getters/setters is a nice thing when using Java style of properties,
> ie. no
> public fields.
Java doesn't have computed attributes, so you have no other choice if
you want to keep your design flexible. For languages that have computed
attributes, this is not a problem to use plain attributes until you
*really* need to do otherwise.
>>> 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
>> Property vs. attribute doesn't make any difference here: both of them
>> are public, and part of the external interface, unless they're named
>> with a leading underscore.
> Nice thing about properites is that they are defined in more
> declarative way -
> in class body. Attributes are "defined" in a piece of code (which can
> be long
> and can contain loops etc.) by assigning a value to 'self'.
Usually, all there is to know is readable in the initializer. And I've
rarely seen (good) code that defines public attribute elsewehere (i've
seen such a thing on a couple occasion, and that's bad coding IMHO).
Anyway, since attributes (including methods, class etc...) can be
added/replaced/deleted by anyone having access to the object at any
point of the program, using properties won't help that much here IMHO.
Not that I don't see your point - I also have a taste for declarative
APIs and readability - but this is enough to justify the use of
More information about the Python-list