How to write Smart Python programs?

Paul Rubin http
Wed Oct 11 06:02:38 EDT 2006


Antoine De Groote <antoine at vo.lu> writes:
> To me this seems contradictory. Why would one not want to do something
> that is included in the documentation? Or am I just confused? Does
> anybody have an idea how to put me in the right direction?

The library reference states the technical procedures for doing
various things.  That is, it explains how the procedures work.  It
doesn't say when to use one procedure or another.  It's a technical
reference, not a style guide.

> And then, by (2) I believe that what is meant is that once some client
> code uses public fields one can't make them private anymore because
> then the clients are broke. That's clear to me. But I don't understand
> (3). I don't know exactly what they mean. How would one want to change
> their mind? In what way? I've been thinking about it some time now,
> but I'm still kept in the dark. I would appreciate any explanation.

I think it means the example you cited from the library doc is
inadvisable in practice, and should only be used as a template for
more complicated getters and setters.  E.g. if you want the client
to be able to set foo.x to an arbitrary value, don't use a setter,
just say

     foo.x = 237

and the attribute value gets set directly.  If you want to limit the
value of foo.x to the range 0-100, and make setting to outside the
range clip to that range or raise an exception or something, THEN use
a setter.  In Python, you can omit the setter at first (so there's no
restriction), then later decide you want to add the restriction, so
you add the setter.  In Java, if you omit the setter at first and then
later want to add it, you have to change all the client calls.



More information about the Python-list mailing list