About the use of **args

Discussion in 'Python' started by Zunbeltz Izaola, Dec 10, 2003.

  1. Hi

    I'm starting a new proyect and i'm in doubt about diferent interfaces
    for my clases. My clases will have a lot of attributes and i'm want to
    know what aproach could be the best

    1) Define one SetAttribute/GetAttribute pair of method for each
    attribute.
    2) Define one SetAttribute/GetAttribute which argument is a key=value
    format.

    Any advaice?

    Thanks in advance

    Zunbeltz Izaola

    --
    Remove XXX from email: X
     
    Zunbeltz Izaola, Dec 10, 2003
    #1
    1. Advertising

  2. On Wed, 10 Dec 2003 09:38:55 +0100, Zunbeltz Izaola wrote:

    > I'm starting a new proyect and i'm in doubt about diferent interfaces
    > for my clases. My clases will have a lot of attributes and i'm want to
    > know what aproach could be the best
    >
    > 1) Define one SetAttribute/GetAttribute pair of method for each
    > attribute.
    > 2) Define one SetAttribute/GetAttribute which argument is a key=value
    > format.


    I asked a similar question myself when I started out with Python, and I
    got some very good answers that served me well.

    http://groups.google.com/groups?hl=...CZ6.1492%24h45.9746%40news.uk.colt.net&rnum=2

    My preferred technique is to just set attributes directly on the object,
    like this:

    shoe = Shoe()
    shoe.laced_up = True
    shoe.is_on_foot = True
    shoe.resoled = False

    You may think that it's a bit nasty because it breaks encapsulation, etc.,
    but Python is designed to let you do stuff quickly and cleanly. You're
    not always in a situation where you need to enforce access so
    strictly. Using attributes directly is more of a Python idiom (see the
    last two posts in the thread I posted earlier).

    Since that earlier thread Python has been given a nice way of
    customising attribute access; properties. Basically, they let you
    define get/set methods that get run when you access/assign to an
    attribute. You benefit by getting a cleaner interface to your class, and
    you only have to define get/set methods when you actually need them (i.e.
    when they have side effects other than getting/setting the attribute).

    For example:

    class Shoe:

    def __init__(self):
    self._laced_up = False
    self.is_on_foot = False
    self.resoled = False

    def _set_laced_up(self, boolean):
    self._laced_up = boolean
    if boolean:
    self.is_on_foot = True

    def _get_laced_up(self):
    return self._laced_up

    laced_up = property(_get_laced_up, _set_laced_up)

    I've not run that so it may have syntax errors. It should illustrate the
    principle though; you can use attributes directly until you want to take
    actions when you set them. Then you can make the attribute "private" and
    replace it with a property that access the real attribute, and does
    whatever else you want to do when it's accessed.

    Hope that makes sense.

    -- Graham
     
    Graham Ashton, Dec 10, 2003
    #2
    1. Advertising

  3. On Wed, 2003-12-10 at 03:24, Graham Ashton wrote:
    > [snip]


    > I've not run that so it may have syntax errors. It should illustrate the
    > principle though; you can use attributes directly until you want to take
    > actions when you set them. Then you can make the attribute "private" and
    > replace it with a property that access the real attribute, and does
    > whatever else you want to do when it's accessed.


    A couple of points on Graham's example:

    1. You have to subclass from object in order to use property.

    2. When Graham nominalizes private, he means that you can still access
    the attribute variable directly--and that's by design.

    See example below.

    Cheers,

    // m

    #!/usr/bin/env python

    class Shoe:

    def __init__(self):
    self._size = None
    def getSize(self):
    print "In getSize..."
    return self._size
    def setSize(self, size):
    print "In setSize..."
    self._size = size
    size = property(getSize, setSize)

    class Shoe2(object):

    def __init__(self):
    self._size = None
    def getSize(self):
    print "In getSize..."
    return self._size
    def setSize(self, size):
    print "In setSize..."
    self._size = size
    size = property(getSize, setSize)

    s = Shoe()
    # Since we haven't subclassed from object, the property descriptor
    # doesn't work; notice that setSize() isn't getting called...
    s.size = 1
    print s.size
    # We can still access the "private" member variable. In Python,
    # private is merely a convention.
    print s._size

    # Now that we've subclassed from object, our get/set methods are
    # called.
    s2 = Shoe2()
    s2.size = 1
    print s2.size
    # And we can still access the "private" member variable.
    print s2._size
     
    Mark McEahern, Dec 10, 2003
    #3
  4. On Wed, 2003-12-10 at 03:24, Graham Ashton wrote:
    > [snip]


    > I've not run that so it may have syntax errors. It should illustrate the
    > principle though; you can use attributes directly until you want to take
    > actions when you set them. Then you can make the attribute "private" and
    > replace it with a property that access the real attribute, and does
    > whatever else you want to do when it's accessed.


    A couple of points on Graham's example:

    1. You have to subclass from object in order to use property.

    2. When Graham nominalizes private, he means that you can still access
    the attribute variable directly--and that's by design.

    See example below.

    Cheers,

    // m

    #!/usr/bin/env python

    class Shoe:

    def __init__(self):
    self._size = None
    def getSize(self):
    print "In getSize..."
    return self._size
    def setSize(self, size):
    print "In setSize..."
    self._size = size
    size = property(getSize, setSize)

    class Shoe2(object):

    def __init__(self):
    self._size = None
    def getSize(self):
    print "In getSize..."
    return self._size
    def setSize(self, size):
    print "In setSize..."
    self._size = size
    size = property(getSize, setSize)

    s = Shoe()
    # Since we haven't subclassed from object, the property descriptor
    # doesn't work; notice that setSize() isn't getting called...
    s.size = 1
    print s.size
    # We can still access the "private" member variable. In Python,
    # private is merely a convention.
    print s._size

    # Now that we've subclassed from object, our get/set methods are
    # called.
    s2 = Shoe2()
    s2.size = 1
    print s2.size
    # And we can still access the "private" member variable.
    print s2._size
     
    Mark McEahern, Dec 10, 2003
    #4
  5. Zunbeltz Izaola

    John Roth Guest

    "Zunbeltz Izaola" <> wrote in message
    news:...
    >
    > Hi
    >
    > I'm starting a new proyect and i'm in doubt about diferent interfaces
    > for my clases. My clases will have a lot of attributes and i'm want to
    > know what aproach could be the best
    >
    > 1) Define one SetAttribute/GetAttribute pair of method for each
    > attribute.
    > 2) Define one SetAttribute/GetAttribute which argument is a key=value
    > format.
    >
    > Any advaice?
    >
    > Thanks in advance
    >
    > Zunbeltz Izaola


    I presume you're talking about constructing the object,
    not about state changes after it's been constructed and
    released into the wild?

    In that case, the "best" pattern is to never let the object
    appear half constructed. There are a wide variety of ways
    of doing this, from passing all the needed parameters into
    the constructor, to numerous variations on the factory
    pattern. And I wouldn't be adverse to the other responder's
    practice of simply plugging values into the instance while
    it's still in the factory: most real world objects don't contain
    the logic for their construction, so why should our programming
    objects?

    John Roth
    >
     
    John Roth, Dec 10, 2003
    #5
  6. Zunbeltz Izaola <> writes:

    > Hi
    >
    > I'm starting a new proyect and i'm in doubt about diferent interfaces
    > for my clases. My clases will have a lot of attributes and i'm want to
    > know what aproach could be the best
    >
    > 1) Define one SetAttribute/GetAttribute pair of method for each
    > attribute.
    > 2) Define one SetAttribute/GetAttribute which argument is a key=value
    > format.
    >
    > Any advaice?


    3) Not have any setters or getters at all.

    Ask yourself: "what is the point of getters and setters?".

    The most common answers are:

    a) Data hiding, privacy, etc.

    b) To protect myself against breaking the interface when I change the
    implementation of my object.

    c) Give you and your users typing exercise.

    In Python there is no enforced data hiding or privacy: you use a
    leading underscore in the identifier name to indicate to your users
    that something is _not_ part of the interface ... so (a) is irrelevant.

    As for (b), Python provides properties, which allow you to replace an
    attribute with a setter and/or a getter method, while maintaining the
    illusion that there is only an attribute. Properties also allow you to
    implement read-only (or write-only! (or delete-only!!)) attributes.

    (I won't comment on (c) :)

    If you are a fan of Bertrand Meyer, you might also answer

    d) Attribute access and method calls should look the same.

    I'm not aware of a Python mechanism to make that irrelevant.
     
    Jacek Generowicz, Dec 10, 2003
    #6
  7. Zunbeltz Izaola

    Duncan Booth Guest

    Mark McEahern <> wrote in
    news::

    > # We can still access the "private" member variable. In Python,
    > # private is merely a convention.
    > print s._size


    Except that in Python the convention for private variables is to begin them
    with two underscore characters, and then it is more than just a convention:

    >>> class Shoe2(object):


    def __init__(self):
    self.__size = None
    def getSize(self):
    print "In getSize..."
    return self.__size
    def setSize(self, size):
    print "In setSize..."
    self.__size = size
    size = property(getSize, setSize)


    >>> s2 = Shoe2()
    >>> s2.size = 1

    In setSize...
    >>> print s2.size

    In getSize...
    1
    >>> print s2.__size


    Traceback (most recent call last):
    File "<pyshell#11>", line 1, in -toplevel-
    print s2.__size
    AttributeError: 'Shoe2' object has no attribute '__size'

    Of course, it doesn't absolutely prevent you accessing the private variable
    if you know what you are doing, but then neither do C++ or Java:

    >>> print s2._Shoe2__size

    1


    --
    Duncan Booth
    int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
    "\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?
     
    Duncan Booth, Dec 10, 2003
    #7
  8. Duncan Booth <> writes:

    > Mark McEahern <> wrote in
    > news::
    >
    > > # We can still access the "private" member variable. In Python,
    > > # private is merely a convention.
    > > print s._size

    >
    > Except that in Python the convention for private variables is to begin them
    > with two underscore characters, and then it is more than just a convention:


    Now, I always believed that "private" in Python is spelt "_", while
    "mangle this name for me because I want to avoid name clashes in
    multiple inheritance scenarios" is spelt "__".

    However, I've heard _so_ many people make the (in my opinion
    incorrect) claim that "private" is spelt "__", that I'm beginning to
    question my sanity.

    Where is the Python spelling of "private" set in stone ?

    I find the suggestion that a mangled name is somehow "more private"
    than one with a single leading underscore, mildly insulting to the
    clients of your code. The implcation is that they can neither work out
    the (very complicated and cryptic[*]) mangling scheme, not use dir().

    If a Python programmer wants to acces a private attribute, he can do
    so, regardless of the number of leading underscores.


    [*] Sarcasm alert. (This alert was brought to you by the International
    Campaign for Promotion of Understanding between Cultures.)
     
    Jacek Generowicz, Dec 10, 2003
    #8
  9. Jacek Generowicz wrote:

    > I find the suggestion that a mangled name is somehow "more private"
    > than one with a single leading underscore, mildly insulting to the
    > clients of your code. The implcation is that they can neither work out
    > the (very complicated and cryptic[*]) mangling scheme, not use dir().


    no, the implication is that they can use their own __variables without
    having to think about what you're calling your private parts.

    in contrast, a _variable is not hidden at all.

    </F>
     
    Fredrik Lundh, Dec 10, 2003
    #9
  10. Zunbeltz Izaola

    Duncan Booth Guest

    Jacek Generowicz <> wrote in
    news::

    >> Except that in Python the convention for private variables is to
    >> begin them with two underscore characters, and then it is more than
    >> just a convention:

    >
    > Now, I always believed that "private" in Python is spelt "_", while
    > "mangle this name for me because I want to avoid name clashes in
    > multiple inheritance scenarios" is spelt "__".
    >
    > However, I've heard _so_ many people make the (in my opinion
    > incorrect) claim that "private" is spelt "__", that I'm beginning to
    > question my sanity.
    >
    > Where is the Python spelling of "private" set in stone ?


    Section 5.2.1 of the Python reference manual in the paragraph headed
    'Private name mangling'.

    >
    > I find the suggestion that a mangled name is somehow "more private"
    > than one with a single leading underscore, mildly insulting to the
    > clients of your code. The implcation is that they can neither work out
    > the (very complicated and cryptic[*]) mangling scheme, not use dir().


    Not at all, the mangling is clearly documented. Its purpose is most
    emphatically NOT to prevent access to your clients.

    >
    > If a Python programmer wants to acces a private attribute, he can do
    > so, regardless of the number of leading underscores.


    Good points. I suppose it all depends on your definition of 'private'. To
    me, there are two reasons why someone might want to use 'private'
    variables. One is to prevent accidental nameclashes when someone subclasses
    one of your classes, the other is because you don't trust those poxy
    programmers who are going to use your class, so you want to burn their
    fingers if they try.

    The first of these, Python provides. Ok, it doesn't get it quite right (the
    name mangling should maybe include the module and package as well as the
    class), but it does a reasonable job of minimising accidental nameclashes.
    Python does not attempt to address the second of these issues, preferring
    to believe that all Python programmers are mature & responsible.

    C++ fails dismally on the first count, it doesn't hide the names so adding
    a 'private member' to a base class can break the derived classes. It also
    fails on the second count, since you can easily bypass private if you wish.

    To my mind, data hiding is a good reason for using private variables, but
    preventing knowledgeable users from bypassing the privacy is dubious at
    best. You are of course free to disagree.

    --
    Duncan Booth
    int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
    "\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?
     
    Duncan Booth, Dec 10, 2003
    #10
  11. Zunbeltz Izaola

    Peter Hansen Guest

    Jacek Generowicz wrote:
    >
    > Duncan Booth <> writes:
    >
    > > Mark McEahern <> wrote in
    > > news::
    > >
    > > > # We can still access the "private" member variable. In Python,
    > > > # private is merely a convention.
    > > > print s._size

    > >
    > > Except that in Python the convention for private variables is to begin them
    > > with two underscore characters, and then it is more than just a convention:

    >
    > Now, I always believed that "private" in Python is spelt "_", while
    > "mangle this name for me because I want to avoid name clashes in
    > multiple inheritance scenarios" is spelt "__".
    >
    > However, I've heard _so_ many people make the (in my opinion
    > incorrect) claim that "private" is spelt "__", that I'm beginning to
    > question my sanity.


    Distinguish "private" and "protected", as in C++ and perhaps wider usage.

    "private" is spelled __ in Python and is supported in a limited fashion
    by the language, while *protected* is spelled _ and is by convention.

    -Peter
     
    Peter Hansen, Dec 10, 2003
    #11
  12. "Fredrik Lundh" <> writes:

    I want to sum up some ideas in the thread:

    1) setters and getters are not mandatory.

    2) The usual way in Python is the direct access

    > [=] ... b.width # is get
    > b.width = # is set
    > del b.width # is del


    3) If when setting some attribute there is necesary to have side
    effects, it can be achive defining __setattr__ and doing the right
    thing depend on the attribute. (It is possible to raise an
    exception when the attribute is not in a list/dictionary of usable
    attributes, to prevent typos and such kind of errors)

    4) __getattr__ can be defined to deal with undefined attributes. For
    example it can handle in different way the attributes in a list of
    permited attributes (see point 3)

    5) attributes that are computed in the fly, can be get like normal
    attributes using "property" (property is new in 2.3 or 2.2?)

    6) attributes and methods that are no part of the user interface are
    named with and _ in the front. (This is a convention)

    Are those ideas correct? We can continue with the discussion!!

    Zunbeltz


    --
    Remove XXX from email: X
     
    Zunbeltz Izaola, Dec 11, 2003
    #12
  13. Zunbeltz Izaola <> writes:

    [snip]

    > 3) If when setting some attribute there is necesary to have side
    > effects, it can be achive defining __setattr__ and doing the right
    > thing depend on the attribute. (It is possible to raise an
    > exception when the attribute is not in a list/dictionary of usable
    > attributes, to prevent typos and such kind of errors)
    >
    > 4) __getattr__ can be defined to deal with undefined attributes. For
    > example it can handle in different way the attributes in a list of
    > permited attributes (see point 3)
    >
    > 5) attributes that are computed in the fly, can be get like normal
    > attributes using "property" (property is new in 2.3 or 2.2?)


    [snip]

    > Are those ideas correct?


    Pretty much.

    Properties are available in 2.2. They only work on new style classes.

    Just about anything that can be done with properties can be done with
    __setattr__ &co, but I think that properties are generally preferred,
    if available.
     
    Jacek Generowicz, Dec 11, 2003
    #13
    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. Ken Varn
    Replies:
    2
    Views:
    649
    Ken Varn
    Jun 22, 2005
  2. Replies:
    3
    Views:
    518
    David Eppstein
    Sep 17, 2003
  3. Pierre Fortin

    args v. *args passed to: os.path.join()

    Pierre Fortin, Sep 18, 2004, in forum: Python
    Replies:
    2
    Views:
    721
    Pierre Fortin
    Sep 18, 2004
  4. er
    Replies:
    2
    Views:
    535
  5. Andrew Tomazos
    Replies:
    5
    Views:
    617
Loading...

Share This Page