Bruno Desthuilliers wrote:
> mystilleef wrote:
> > Bruno Desthuilliers wrote:
> >
> >>mystilleef wrote:
> (snip)
> >>>>>
> >>>>>Of course using setters for the sake of just using them is pointless.
> >>>>
> >>>>Indeed.
> >>>>
> >>>>
> >>>>
> >>>>>The reason to use them is if pre-conditions or post-conditions need to
> >>>>>be met. Or to control access to an objects states.
> >>>>
> >>>>Then why advocate *systematic* use of them ?
> >>>>
> >>>>(snip)
> >>>
> >>>I never advocated anything.
> >>
> >>You advocated
> >>"""
> >>1). Make all attributes of a class private/protected .
> >>2). If a "non-callable" attribute is going to be used outside a class,
> >>think about making it a property and name the property well, because
> >>you never know...
> >>"""
> >>
> >
> >
> > You use accessors when you need to control access to a data attribute.
>
> Indeed. And when you don't need too ? (the second 'o' is not a typo)
>
You make the attribute private/protected.
> > That's not advocacy, that's common sense.
>
> I'm afraid we don't use the same definition of "common sense". Writing
> useless code is not part of my definition of "common sense".
>
> (snip)
> >>>
> >>>I agree. And I already told you I think in terms of state and behavior
> >>>and not language dependent semantics.
> >>
> >>Then why do you advise "(making) all attributes of a class
> >>private/protected" and systematically using properties ?
> >>
> >
> >
> > Because you don't want third parties illegimately tampering with an
> > object's internal data and thus crashing your system?
>
> Let's try again...
>
> point 1 : there's *no* language-inforced access restriction in Python.
> Just a *convention*.
>
Huh? What are properties for then?
> point 2 : so anyone *can* "illegimately tampering with an object's
> internal data" at will.
>
And this is robust how?
> point 3 : anyway it's not *my* system that will then crash - but the
> system of the one who "illegimately" played with my package's objects
> internals. And as far as I'm concerned, it's none of my problem - they
> were marked as implementation, so anyone playing with them is on it's
> own. FWIW, I suspect that if someone want to muck with implementation,
> he certainly has a good legitimate reason to do so, and will do her best
> to not break anything. Else he's a complete idiot and there's no cure
> for this.
>
You can't be serious. Please tell me you are joking.
> point 4 : since we have computed attributes, turning a "public data
> attribute" (to use your idiom) into a "private/protected data attribute
> with accessors" *without breaking the interface* is not even a non-brainer.
>
> Now, please, can you explain the difference between :
>
> class Complicated(object):
> def __init__(self, data):
> self.data = data
> def _get_data(self):
> return self._data
> def _set_data(self, data):
> self._data = data
>
> and
>
> class Pragmatic(object):
> def __init__(self, data)
> self.data = data
>
>
> and find any *valid* reason to use the first solution instead of the
> second ? ('that's what the book says' not being a valid reason).
>
I don't know it's your code not mine.
class Robust(object):
def __init__(self):
# Arbitrarily changing this state to False will crash app or
will
# corrupt the whole event system.
self.__is_active = True
def get_is_active(self):
return self.__is_active
buffer_is_active = property(get_is_active, doc="True if buffer is
editable")
def monitor_events(self):
# Only methods of this class can change __is_active.
# Add code to change __is_active here.
return
See! I'm controlling access. Whee! And if one sober morning I want to
change the name __is_active to __buffer_is_active, I won't have to hunt
down 27000 lines of code to do it. Also a naive third party won't crash
my system by changing Robust's state arbitrarily. Because in the real
world when your program is buggy, you get bug reports, nasty emails
among other forms of ridicule. And your supposed solution to my problem
is me saying, "but...but...I told you not change is_active." Ha! And if
you can't figure out why anyone would do this, then I'm not wasting my
time here anymore. Someday you'll learn the hard way.
Thanks to the people who exposed me to Python's properties.
Bye
--
http://mail.python.org/mailman/listinfo/python-list
