On Aug 16, 1:22 am, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: > Rafea écrit : > > > Hi, > > > I've been thinking in circles about these aspects of Pythonic design > > and I'm curious what everyone else is doing and thinks. There are 3 > > issues here: > > > 1) 'Declaring' attributes > > There's nothing like "declaration" of variables/attributes/whatever in > Python. > > > - I always felt it was good code practice to > > declare attributes in a section of the class namespace. I set anything > > that is constant but anything variable is set again in __init__(): > > > Class A(object): > > name = "a name" > > type = "a typee" > > childobject = None > > > def __init__(self, obj): > > self.childobject = object > > > This makes it easy to remember and figure out what is in the class. > > Granted there is nothing to enforce this, but that is why I called it > > 'code practice'. Do you agree or is this just extra work? > > It's not only extra work, it's mostly a WTF. You create class attributes > for no other reasons than to mimic some other mainstream languages. If I > was to maintain such code, I'd loose valuable time wondering where these > class attributes are used. > > > > > 2) Internal attributes (starting with 2x'_') aren't inherited. > > Yes they are. But you need to manually mangle them when trying to access > them from a child class method. FWIW, that *is* the point of > __name_mangling : making sure these attributes won't be accidentally > overwritten in a child class. > > > Do you > > just switch to a single '_' when you want an "internal" attribute > > inherited? These are attributes I want the classes to use but not the > > user of these classes. Of course, like anything else in Python, these > > aren't really private. It is just a convention, right? (The example > > for #3 shows this.) > > Yes. The (*very* strong) convention is that > _names_with_simple_leading_underscore denote implementation attributes. > > > > > 3) It isn't possible to override a piece of a Property Descriptor. To > > get around this, I define the necessary functions in the class but I > > define the descriptor in the __new__() method so the inherting class > > can override the methods. Am I overlooking some basic design principle > > here? This seems like a lot of work for a simple behavior. Example: > > > class Base(object): > > def __new__(cls): > > setattr(cls, > > "state", > > property(fget = cls._Get_state, > > fset = cls._Set_state, > > fdel = None, > > doc = cls._doc_state)) > > > obj = super(Base, cls).__new__(cls) > > return obj > > > state = None # Set in __new__() > > _state = True > > _doc_state = "The state of this object" > > def _Get_state(self): return self._state > > def _Set_state(self, value): self._state = value > > pep08 : attribute names (including methods) should be all_lower. > > > class Child(Base): > > def _Get_state(self): > > # Do some work before getting the state. > > print "Getting the state using the child's method" > > return self._state > > > print Child().state > > How often do you really need to override a property ? (hint : as far as > I'm concerned, it never happened so far). Now you have two solutions : > either redefine the whole property in the derived class, or, if you > really intend your property to be overriden, provide a "template method" > hook. > > I'd say you're making things much more complicated than they need to be.
Thanks Bruno, and everyone ! These are exactly the type of hard answers I was hoping for. I'm mostly converted but my brain still needs a Pythonic push from time to time. Looks like have some some clean up to perform...with confidence. I'm interested to see the implementation of getter, etc overrides in 2.6/3.0. I have two classes that could be simplified with this. For example, I have a class which does a lot of work and has about 5 key properties. I want to inherit it, and just trigger an event (update something only stored in the child) after 4 of these attributes are finished being set. I was thinking about using a callback which is empty in the parent or __setattr__() (but I hat using this unless I have to, it is still troublesome to me). - Rafe -- http://mail.python.org/mailman/listinfo/python-list
