[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-list
Subject:    Re: Use cases for del
From:       "George Sakkis" <gsakkis () rutgers ! edu>
Date:       2005-07-08 0:31:52
Message-ID: 1120782711.956892.302970 () g44g2000cwa ! googlegroups ! com
[Download RAW message or body]

"Grant Edwards" <grante@visi.com> wrote:

> On 2005-07-07, George Sakkis <gsakkis@rutgers.edu> wrote:
>
> > I guess he means why not define foo as property:
> >
> > class demo(object):
> >     foo = property(fget = lambda self: self.v,
> >                    fset = lambda self,v: setattr(self,'v',v))
> >
> > d = demo()
> > d.foo = 3
> > print d.foo
>
> In some ways that's even cleaner.
>
> In my simplivied example all the foo() method was doing was
> setting/returning an attribute, but usually there's a bit more
> going on (e.g. system calls with possible side effects).
>
> To me it's a bit more explicit that
>
>   d.foo(3)
>   d.foo()
>
> are doing something other than just getting/setting the value
> of an instance attribute.  If all I really wanted to do was
> get/set the instance's "v" attribute, I probably would have
> just done it like this
>
>   d.v = 3
>   print d.v

The main reason for bringing properties into the language was exactly
to *hide* the fact that something else might be going one behind the
scenes. Ideally, the user of the class shouldn't care [1] whether
getting an attribute returns a stored value in the instance's __dict__,
computes it on the fly, fetches it from a cache or a database, etc, and
similarly for setting the attribute.

George

[1] OTOH the user should probably be aware if a specific property (or
any callable for that matter) implies significant performance (or
other) costs.

-- 
http://mail.python.org/mailman/listinfo/python-list
[prev in list] [next in list] [prev in thread] [next in thread]