Does Python really follow its philosophy of "Readability counts"?

Russ P. Russ.Paielli at gmail.com
Tue Jan 20 04:09:50 CET 2009


On Jan 19, 6:24 pm, Steven D'Aprano
<ste... at REMOVE.THIS.cybersource.com.au> wrote:
> On Mon, 19 Jan 2009 18:07:50 -0800, Russ P. wrote:
> > On Jan 19, 5:09 pm, Luis Zarrabeitia <ky... at uh.cu> wrote:
>
> >> Russ, I think _you_ are missing the point. If the attribute is already
> >> public, why does it need properties? Why would a programmer go to the
> >> trouble of adding them manually, just to get one level of indirection
> >> for an already public attribute?
>
> > You don't understand the purpose of properties -- and you tell me that
> > *I* am the one missing the point?
>
> Well, I *thought* I did, and (unlike Bruno) I'm not hostile to the idea
> Russ is proposing. But I must admit it's not clear to me why Russ thinks
> it is a good idea to automatically turn this:
>
> class Parrot(object):
>     def __init__(self):
>         self.x = 1
>
> into this:
>
> class Parrot(object):
>     def __init__(self):
>         self._x = 1
>     def getx(self):
>         return self._x
>     def setx(self, value):
>         self._x = value
>     x = property(getx, setx)
>
> Because frankly, that's how I read Russ' explanation for what Scala is
> doing. Have I missed something?
>
> --
> Steven

Whoops, I accidentally hit send on the last post.

One of the main benefits of properties is that they allow you to more
safely put attributes in the public interface. If you later decide
that the attribute shouldn't have been in the public interface, you
can convert it to a property and make it do whatever you want it to
do. That won't always save you, but sometimes it can.

As a trivial example, suppose you have a circle class with public
attributes of radius and area. You later realize that it is unwise to
let the user change one without changing the other, leaving them
inconsistent. With properties, you can convert them each to a property
and write functions to force consistency.

The benefit of automatically converting public data into properties, I
assume, is to relieve the programmer of doing it manually. The
programmer will obviously need to add any functionality when needed,
but he does not need to create the function header.

I don't know the implications for efficiency in Scala. Perhaps there
is a slight cost for one level of indirection. But please recall that
public data is supposed to be rarely if ever used anyway. Unlike some
folks here, the Scala folks understand the value of encapsulation and
data hiding.



More information about the Python-list mailing list