Accessors in Python (getters and setters)

FAQ

Memberlist

Usergroups

Profile

Preferences

· nixdoc.net

· man pages

· Linux HOWTOs

· FreeBSD Tips

· Forums

Forum index » Programming » python

Accessors in Python (getters and setters)

Page 7 of 8 [116 Posts]

View previous topic :: View next topic
Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8 Next

Author

Message

Steve Holden
*nix forums Guru

Joined: 22 Feb 2005
Posts: 1255

Posted: Thu Jul 20, 2006 7:02 am Post subject: Note

Re: Accessors in Python (getters and setters)

Dennis Lee Bieber wrote:

Quote:

On 19 Jul 2006 22:38:17 -0700, "mystilleef" <mystilleef@gmail.com
declaimed the following in comp.lang.python:

permitted should be between an object and its mediator. Messages are
passed through the system via signals or events or established
protocols. What are the benefits? Well I can change the implementation
of any object at will without breaking the whole system. Or I can even

Python permits that using properties... But one doesn't have to code
the properties from the get-go... Development can be done with direct
attribute access, and if it is determined that some sort of conditioning
logic is needed, it can be implemented WITHOUT CHANGING THE API.

This IS an "established protocol" in Python.

High coupling is bad. Exposing critical states of an object is bad. Any
decent computer science book will tell you that.

In Python, using, if needed, properties, this is transparent... The
user of the object doesn't know, or need to know, if it is state or
behavior -- all it sees is that it supplies a value for something,
and/or retrieves a value for something.

Obviously if I want to control access to an attribute, it means I don't
want it altered or I want to perform pre/post conditional computations
before/after the attribute is accessed. There's a reason it is called
access control.

Python properties support this, no need to have the user of the
object explicitly call a getter or setter...

changing states you never bothered to hide to begin with, then the
wisdom behind careful upfront planning begins to make sense.

If it isn't part of the documented API, it is the user's fault. That
applies to all software...

I'm this thread represents proof tht you can lead a horse to water but
you can't make him drink - especially when he thinks the water is
Kool-Aid, and that attribute APIs can be abused in ways that
method-based ones can't.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

Steve Holden
*nix forums Guru

Joined: 22 Feb 2005
Posts: 1255

Posted: Thu Jul 20, 2006 7:15 am Post subject: Note

Re: Accessors in Python (getters and setters)

mystilleef wrote:
[...]

Quote:

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")

Let's ignore changes of state for the moment. The mystical difference

that makes read access via

some_robust.buffer_is_active()

acceptable and

some_robust.__is_active

somehow dangerous (ignoring the fact that name_mangling will take place)
is what?

Quote:

def monitor_events(self):
# Only methods of this class can change __is_active.
# Add code to change __is_active here.
return

I'm sure nobody would argue that if close synchronization between

multiple attributes is required then write accessors are a bad idea. But
using them unnecessarily just makes your code heavier, slower and less
easy to maintain.

Quote:

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.

It's way too late. My comments *are* based on engineering experience.

One day you may realise that unnecessary complexity is a far bigger time
waster than any imagined problems of direct attribute access. I suspect
that if you are getting complaints if the nature you describe it's just
because your software isn't that good.

Quote:

Thanks to the people who exposed me to Python's properties.

Bye

Really? Promise? I fear we are arguing from different premises.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

mystilleef@gmail.com
*nix forums beginner

Joined: 11 Oct 2005
Posts: 46

Posted: Thu Jul 20, 2006 8:50 am Post subject: Note

Re: Accessors in Python (getters and setters)

Steve Holden wrote:

Quote:

buffer_is_active is not a method, it's a property. So:

some_robust.buffer_is_active

is appropriate.

Quote:

acceptable and

some_robust.__is_active

somehow dangerous (ignoring the fact that name_mangling will take place)
is what?

We can't ignore name mangling. That's an illegal statement in Python.
So it is less dangerous.

Quote:

def monitor_events(self):
# Only methods of this class can change __is_active.
# Add code to change __is_active here.
return

I'm sure nobody would argue that if close synchronization between
multiple attributes is required then write accessors are a bad idea. But
using them unnecessarily just makes your code heavier, slower and less
easy to maintain.

Ah, I broke my own rule. That method is supposed to be private too.
Meaning no one can change the state of the object except the object
itself. The code is below

def __monitor_event(self):
# Perform whatever needs to be done to change state
return

__monitor_event is not supposed to be a write accessor. My point was
show how you can change the state of an object internally without
needing external access to it. Since some people are surprisingly
claiming it is not possible.

Quote:

And mine are based on future engineering predictions? Okay, one day I
shall see the light.

Quote:

Thanks to the people who exposed me to Python's properties.

Bye

Really? Promise? I fear we are arguing from different premises.

Yes, we are. We have been since about the 5th post on this thread if
you haven't noticed.

bruno modulix
*nix forums Guru

Joined: 21 Feb 2005
Posts: 819

Posted: Thu Jul 20, 2006 10:48 am Post subject: Note

Re: Accessors in Python (getters and setters)

mystilleef wrote:

Quote:

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.

doh :(

Let's talk about psychorigid mindset...

Quote:

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?

To allow attribute syntax when you really have computation behind. Which
1/ let you start with the simplest case (a simple attribute) and change
your mind latter
2/ offer the possibility to use an attribute syntax (instead of a method
call syntax) when it seems more natural.

Quote:

point 2 : so anyone *can* "illegimately tampering with an object's
internal data" at will.

And this is robust how?

You can do just the same in Java or C++.

Quote:

I'm deadly serious and definitively not joking. There's no cure for
idiocy, and there's definitively nothing like an idiot-proof system.

Quote:

IOW : you're unable to find any valid reason to use the second solution
instead of the first (of course : there's none), but refuse to admit it.

Quote:

Yuck.

Quote:

See! I'm controlling access.

You are not controlling *anything*

r = Robust()
r._Robust__is_active = True

As I told you, there's no cure for idiocy.

Quote:

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.

And what if you want to change 'buffer_is_active' to 'is_active' ?

Quote:

Also a naive third party won't crash
my system by changing Robust's state arbitrarily.

Lol. cf above. And, may I repeat : you're getting the "my/3rd part"
stuff the wrong way. If someone uses your code in it's app, then it's
*her* system, and *your* code is the '3rd part'. Whether someone wants
to do idiotic things with your code that will result in a crash is none
of *your* concern. Just like if someone buy a hammer and bangs his head
with, it's not the concern of the guy who made the hammer.

Quote:

Because in the real
world when your program is buggy, you get bug reports, nasty emails
among other forms of ridicule.

So you see receiving a bug report as a form of ridicule ?

Now FWIW, I have lot of python apps in production, very few bug reports
[1], and none of them being the result of the problem you seems to fear
that much.

[1] The very first release of one of them is in production for more than
6 monthes now, is daily used by a dozen non-computer-savy users, and not
a *single* bug report - actually, the only return we had is "it's
perfect, it works like a charm, and we have some other stuff for you guys"

Quote:

And your supposed solution to my problem
is me saying, "but...but...I told you not change is_active."

In my example (which was not intended as a "solution to a problem"),
is_active is clearly part of the API. So your argument is moot.

OTOH, if I need to control access to is_active, I can easily change it's
implementation - ie by using a property (or any custom descriptor). So
my "solution to the problem" is functionally equivalent to yours, and
requires much less code - which contributes to making it more robust.

Quote:

Ha! And if
you can't figure out why anyone would do this,

Oh yes, I can :
- too much exposure to B&D languages
- lack of ability to criticize "what's in the Book"
- confusion between state/behaviour concepts and the (mostly inexisting
in most hi-level languages) data/function dichotomy
- control-freak mindset

Quote:

then I'm not wasting my
time here anymore.

You're wasting your time because you refuse to escape from your "what's
in the book" mindest and insist on writing Java in Python. I had the
same problem when I came from Java to Python, then I had the "aha"
moment where I realized I was overdoing it, writing uselessly
complicated code to do simple things that would just have worked without
all this mumbo/jumbo control freak stuff. But it seems you prefer to
stick to your masochistic approach for no other reason than
misunderstood concepts, so we can't help you here.

Quote:

Someday you'll learn the hard way.

Lol. I actually did *un*learn the hard way.

Mystilleef, I've started programing 17 years ago, and have done it
professionnaly for almost 10 years now. I do not pretend to be a good
programmer, but please believe that I do know my job. I've read the Book
too, I've tried applying it blindly, then I used my brain. Once you
understand the real reasons behind a "rule", you also understand when
and how to apply or not apply it.

Quote:

Thanks to the people who exposed me to Python's properties.

The problem is that you definitively *failed* to understand how to use
them (or actually how to *not* use them when not needed).

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"

bruno modulix
*nix forums Guru

Joined: 21 Feb 2005
Posts: 819

Posted: Thu Jul 20, 2006 10:52 am Post subject: Note

Re: Accessors in Python (getters and setters)

Dennis Lee Bieber wrote:

Quote:

On Wed, 19 Jul 2006 18:54:55 +0200, Bruno Desthuilliers
onurb@xiludom.gro> declaimed the following in comp.lang.python:

Indeed. And when you don't need too ? (the second 'o' is not a typo)

Pardon, but for the sense you intend, it should be:

... don't need, too?

Granted. Actually, it *was* a typo - but it happened to also make sens,
so I decided it was not a typo !-)

But I promise I'll be more carefull next time.

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"

Gerhard Fiedler
*nix forums beginner

Joined: 12 Jul 2006
Posts: 18

Posted: Thu Jul 20, 2006 11:29 am Post subject: Note

Re: Accessors in Python (getters and setters)

On 2006-07-20 04:15:33, Steve Holden wrote:

Quote:

mystilleef wrote:
[...]

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")

Let's ignore changes of state for the moment. The mystical difference
that makes read access via

some_robust.buffer_is_active()

acceptable and

some_robust.__is_active

somehow dangerous (ignoring the fact that name_mangling will take place)
is what?

def monitor_events(self):
# Only methods of this class can change __is_active.
# Add code to change __is_active here.
return

I'm sure nobody would argue that if close synchronization between
multiple attributes is required then write accessors are a bad idea. But
using them unnecessarily just makes your code heavier, slower and less
easy to maintain.

I'm not sure, but there's one thing that has a potential to be the real
issue: what's the common way to create a property that is read-write for
the implementation and "read-only" for the interface? It seems to me that
this is what mystilleef is trying to do.

I know that Python doesn't really provide access control. But so far I've
learned that a leading underscore says "I'm implementation, don't touch me
unless you know what you're doing". So I imagine that I browse through code
and look for leading underscores for non-local object attributes, to spot
troublespots. So I imagine that using such attributes as "read-only"
interface elements may not be a good idea, because then you not only have
to spot them in outside code, you always also have to check whether that's
a read or a write access (to know whether it's something potentially
dangerous or not). I also don't know how you could use the computed
attribute methods to do different things for access from the outside and
from the inside (of the object).

So... _is_active is considered implementation. Don't mess with me, it says.
But the users of the class need access to it: read access. Do you just say
"read access isn't changing anything, so just use _is_active"? The
disadvantage is that the outside code is sprinkled with accesses to
attributes with leading underscores, which I assume looks kind of scary. Or
do you rename _is_active to is_active, indicating that access to it is
indeed allowed? Then you would have to do something in the attribute
accessors to control the write access -- because that still isn't a good
idea. But I need want to be able to write to it from inside the class...
but how, if the attribute accessor is preventing that? Is there a local
override for that? I'm sure there is... but is it a common technique?

I may have not used the correct terminology for everything, but I think
it's possible to parse that :)

And maybe that helps putting this to rest and make everybody happy :)

Gerhard

Steve Holden
*nix forums Guru

Joined: 22 Feb 2005
Posts: 1255

Posted: Thu Jul 20, 2006 11:40 am Post subject: Note

Re: Accessors in Python (getters and setters)

Gerhard Fiedler wrote:

Quote:

On 2006-07-20 04:15:33, Steve Holden wrote:

mystilleef wrote:
[...]

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")

Let's ignore changes of state for the moment. The mystical difference
that makes read access via

some_robust.buffer_is_active()

acceptable and

some_robust.__is_active

somehow dangerous (ignoring the fact that name_mangling will take place)
is what?

def monitor_events(self):
# Only methods of this class can change __is_active.
# Add code to change __is_active here.
return

I'm sure nobody would argue that if close synchronization between
multiple attributes is required then write accessors are a bad idea. But
using them unnecessarily just makes your code heavier, slower and less
easy to maintain.

I'm not sure, but there's one thing that has a potential to be the real
issue: what's the common way to create a property that is read-write for
the implementation and "read-only" for the interface? It seems to me that
this is what mystilleef is trying to do.

I know that Python doesn't really provide access control. But so far I've
learned that a leading underscore says "I'm implementation, don't touch me
unless you know what you're doing". So I imagine that I browse through code
and look for leading underscores for non-local object attributes, to spot
troublespots. So I imagine that using such attributes as "read-only"
interface elements may not be a good idea, because then you not only have
to spot them in outside code, you always also have to check whether that's
a read or a write access (to know whether it's something potentially
dangerous or not). I also don't know how you could use the computed
attribute methods to do different things for access from the outside and
from the inside (of the object).

So... _is_active is considered implementation. Don't mess with me, it says.
But the users of the class need access to it: read access. Do you just say
"read access isn't changing anything, so just use _is_active"? The
disadvantage is that the outside code is sprinkled with accesses to
attributes with leading underscores, which I assume looks kind of scary. Or
do you rename _is_active to is_active, indicating that access to it is
indeed allowed? Then you would have to do something in the attribute
accessors to control the write access -- because that still isn't a good
idea. But I need want to be able to write to it from inside the class...
but how, if the attribute accessor is preventing that? Is there a local
override for that? I'm sure there is... but is it a common technique?

I may have not used the correct terminology for everything, but I think
it's possible to parse that :)

And maybe that helps putting this to rest and make everybody happy :)

The logical way would seem to be to provide a read property is_active()

only. The implementation can access the _is_active instance variable
that the property exposes, writing it as necessary. If the accessor
gives direct access to the variable there's no need to use it inside the
object implementation. Or have I misunderstood your requirements?

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

Diez B. Roggisch
*nix forums Guru

Joined: 20 Feb 2005
Posts: 882

Posted: Thu Jul 20, 2006 12:03 pm Post subject: Note

Re: Accessors in Python (getters and setters)

Quote:

To second that:

"""
A Foolish Consistency is the Hobgoblin of Little Minds
"""

http://www.python.org/dev/peps/pep-0008/

Diez

bruno modulix
*nix forums Guru

Joined: 21 Feb 2005
Posts: 819

Posted: Thu Jul 20, 2006 12:31 pm Post subject: Note

Re: Accessors in Python (getters and setters)

mystilleef wrote:
(snip)

Quote:

__monitor_event is not supposed to be a write accessor. My point was
show how you can change the state of an object internally without
needing external access to it. Since some people are surprisingly
claiming it is not possible.

I failed to see anyone making such a claim.

(snip)

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"

bruno modulix
*nix forums Guru

Joined: 21 Feb 2005
Posts: 819

Posted: Thu Jul 20, 2006 12:40 pm Post subject: Note

Re: Accessors in Python (getters and setters)

Gerhard Fiedler wrote:
(snip)

Quote:

I'm not sure, but there's one thing that has a potential to be the real
issue: what's the common way to create a property that is read-write for
the implementation and "read-only" for the interface?

class Foo(object):
@apply
def _imp():
def fget(self):
# code here
def fset(self, val):
# code here
return property(**locals())

@apply
def api():
def fget(self):
return self._imp
def fset(self, val):
raise SomeException('read-only, sorry')
return property(**locals())

(snip)

Quote:

So... _is_active is considered implementation. Don't mess with me, it says.
But the users of the class need access to it: read access. Do you just say
"read access isn't changing anything, so just use _is_active"?

Certainly not.

Quote:

The
disadvantage is that the outside code is sprinkled with accesses to
attributes with leading underscores, which I assume looks kind of scary. Or
do you rename _is_active to is_active, indicating that access to it is
indeed allowed?

Certainly not (given I want is_active to be read-only).

Quote:

Then you would have to do something in the attribute
accessors to control the write access -- because that still isn't a good
idea. But I need want to be able to write to it from inside the class...
but how, if the attribute accessor is preventing that?

Note that a read-only property named 'is_active' returning the value of
an attribute named '_is_active' doesn't prevent direct access to
'_is_active' attribute, neither from the class nor from the client code.

HTH
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"

mystilleef@gmail.com
*nix forums beginner

Joined: 11 Oct 2005
Posts: 46

Posted: Thu Jul 20, 2006 1:44 pm Post subject: Note

Re: Accessors in Python (getters and setters)

Bruno Desthuilliers wrote:

Quote:

mystilleef wrote:
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.

doh :(

Let's talk about psychorigid mindset...

Thanks, I'm insane.

Quote:

Right, and what I'm I trying to do again?

Quote:

point 2 : so anyone *can* "illegimately tampering with an object's
internal data" at will.

And this is robust how?

You can do just the same in Java or C++.

OMG!

Quote:

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.

I'm deadly serious and definitively not joking. There's no cure for
idiocy, and there's definitively nothing like an idiot-proof system.

Sure, but calling users idiots for as result of your laziness or poor
design or lack of robustness is equally idiotic.

Quote:

Hey, I didn't write that code. You did! You deal with it. My input on
__your__ code at this point is irrelevant.

Quote:

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

Yuck.

See! I'm controlling access.

You are not controlling *anything*

r = Robust()
r._Robust__is_active = True

*sighs*

You keep coming up with these unrealistic and impractically delusional
theories to make yourself feel happy. Sure Python lets your do that,
but that's an implementation detail almost all Python developers could
give a damn about. How many times do I have to tell you I don't care
for latent semantic implementation details of Python? Anybody who does
what you just did should be laughed at derisively and ignored. But I
don't have time to deal with fantasy and unreleastic theories.

Quote:

As I told you, there's no cure for idiocy.

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.

And what if you want to change 'buffer_is_active' to 'is_active' ?

But I don't want to. I wanna change implementation not interface.

Quote:

Also a naive third party won't crash
my system by changing Robust's state arbitrarily.

Lol. cf above. And, may I repeat : you're getting the "my/3rd part"
stuff the wrong way. If someone uses your code in it's app, then it's
*her* system, and *your* code is the '3rd part'. Whether someone wants
to do idiotic things with your code that will result in a crash is none
of *your* concern. Just like if someone buy a hammer and bangs his head
with, it's not the concern of the guy who made the hammer.

That's just silly. If a third party plugin is crashing your app, guess
who's gonna get the emails and bug reports? That's right you! And that
is after hours of trying to reproduce the bug on your system
unsuccessfully because you don't have the bloody plug-in installed and
they user doesn't know a random plug-in he downloaded is the root of
the problem. Welcome to reality.

Quote:

Because in the real
world when your program is buggy, you get bug reports, nasty emails
among other forms of ridicule.

So you see receiving a bug report as a form of ridicule ?

Yes, it can be.

Quote:

Now FWIW, I have lot of python apps in production, very few bug reports
[1], and none of them being the result of the problem you seems to fear
that much.

Good for you! I'm sure you are brilliant programmer.

Quote:

[1] The very first release of one of them is in production for more than
6 monthes now, is daily used by a dozen non-computer-savy users, and not
a *single* bug report - actually, the only return we had is "it's
perfect, it works like a charm, and we have some other stuff for you guys"

My users are not just end users they are also developers. Again, I'm
glad you are seeing success in __your__ projects.

Quote:

And your supposed solution to my problem
is me saying, "but...but...I told you not change is_active."

In my example (which was not intended as a "solution to a problem"),
is_active is clearly part of the API. So your argument is moot.

OTOH, if I need to control access to is_active, I can easily change it's
implementation - ie by using a property (or any custom descriptor). So
my "solution to the problem" is functionally equivalent to yours, and
requires much less code - which contributes to making it more robust.

Your example actually requires more code, is looks complex and it's
ugly (no offense, my opinion).

Quote:

Ha! And if
you can't figure out why anyone would do this,

Oh yes, I can :
- too much exposure to B&D languages
- lack of ability to criticize "what's in the Book"
- confusion between state/behaviour concepts and the (mostly inexisting
in most hi-level languages) data/function dichotomy
- control-freak mindset

Lets stick to the arguments please. No need to attack me.

Quote:

then I'm not wasting my
time here anymore.

You're wasting your time because you refuse to escape from your "what's
in the book" mindest and insist on writing Java in Python. I had the
same problem when I came from Java to Python, then I had the "aha"
moment where I realized I was overdoing it, writing uselessly
complicated code to do simple things that would just have worked without
all this mumbo/jumbo control freak stuff. But it seems you prefer to
stick to your masochistic approach for no other reason than
misunderstood concepts, so we can't help you here.

Fantastically, I have never used Java for any public project. I don't
understand how you reach your faulty assumptions. You don't know my
background with any language so quit this "Java is the reason you think
like this" banter.

Quote:

Someday you'll learn the hard way.

Lol. I actually did *un*learn the hard way.

Mystilleef, I've started programing 17 years ago, and have done it
professionnaly for almost 10 years now. I do not pretend to be a good
programmer, but please believe that I do know my job. I've read the Book
too, I've tried applying it blindly, then I used my brain. Once you
understand the real reasons behind a "rule", you also understand when
and how to apply or not apply it.

What book are we talking about again? I made these rules from my
experience writing programs in Python, not from any book. There's only
so much books can do when it comes to designing robust software in
practice. But for a lot of people over here who claim they've been
programming for X number of years, some of them certainly do need to
hit the books again. I don't believe I spent an inordinate amount of
time explaining state and behavior or the benefits or techniques for
reducing coupling or why anyone would need accessors, among other
things.

Quote:

Thanks to the people who exposed me to Python's properties.

The problem is that you definitively *failed* to understand how to use
them (or actually how to *not* use them when not needed).

Sure, if it makes you feel better.

bruno modulix
*nix forums Guru

Joined: 21 Feb 2005
Posts: 819

Posted: Thu Jul 20, 2006 2:47 pm Post subject: Note

Re: Accessors in Python (getters and setters)

mystilleef wrote:

Quote:

Bruno Desthuilliers wrote:

(snip)
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.

doh :(

Let's talk about psychorigid mindset...

Thanks, I'm insane.

You say so.

(snip)

Quote:

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?

To allow attribute syntax when you really have computation behind. Which
1/ let you start with the simplest case (a simple attribute) and change
your mind latter
2/ offer the possibility to use an attribute syntax (instead of a method
call syntax) when it seems more natural.

Right, and what I'm I trying to do again?

Write Java in Python.

Quote:

point 2 : so anyone *can* "illegimately tampering with an object's
internal data" at will.

And this is robust how?

You can do just the same in Java or C++.

OMG!

It's common knowledge.

Quote:

Ok, then 99.99% of Python programmers are lazy, have poor design skills
and are unable to write a robust application. So they are idiotic too.

Quote:

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.

IOW : you're unable to find any valid reason to use the second solution
instead of the first (of course : there's none), but refuse to admit it.

Hey, I didn't write that code. You did! You deal with it. My input on
__your__ code at this point is irrelevant.

It's totally relevant, and you're still unable to come with any valid
reason to prefer the first solution over the second. I'm totally
confident that if there was *any* defendable reason to favor the first
approach, you'd have chosen to answer instead of playing dumb.

Quote:

Pardon ? Which "unrealistic and impractically delusional theories" ?
Please try the code above instead of getting to big words...

Quote:

to make yourself feel happy.

yes, of course, I need this to feel happy. Doh :(

Quote:

Sure Python lets your do that,
but that's an implementation detail almost all Python developers could
give a damn about. How many times do I have to tell you I don't care
for latent semantic implementation details of Python? Anybody who does
what you just did should be laughed at derisively and ignored.

Believe it or not, but there are times someone may have a perfectly
valid reason to do so (probably not with your example, but that's
another point).

Quote:

But I
don't have time to deal with fantasy and unreleastic theories.

blah blah.

Quote:

Changing implementation from direct attribute access to property doesn't
require changing the interface, so there's no reason to use a property
for simple read/write access. period.

Quote:

Not my responsability.

Quote:

guess
who's gonna get the emails and bug reports? That's right you!

And ?

Quote:

And that
is after hours of trying to reproduce the bug on your system
unsuccessfully

If the app runed fine and all of a sudden starts to crash, I'll suspect
something specific to the user system.

Quote:

because you don't have the bloody plug-in installed and
they user doesn't know a random plug-in he downloaded is the root of
the problem.

"Hi Mr User... Just a question about your problem : did you change
anything in your system recently ? Like installing a new plugin ?"

Quote:

Because in the real
world when your program is buggy, you get bug reports, nasty emails
among other forms of ridicule.

So you see receiving a bug report as a form of ridicule ?

Yes, it can be.

I definitively give up trying to understand you.

Quote:

I'm not.

Quote:

Developpers are supposed to know enough to fill in useful bug reports...
and possibly do some prior research on the problem by themselves.

Quote:

Which one ?

Quote:

actually requires more code,
is looks complex and it's
ugly

You mean:

class Pythonic(object):
def __init__(self):
self._is_active = True

@apply
def is_active():
def fget(self): return self._is_active
def fset(self): raise SomeException('sorry, read-only')
return property(**locals())

Quote:

(no offense, my opinion).

of course.

Quote:

You're of course free to identify yourself with the 'anyone' described
above - but that's your responsability, not mine.

Quote:

Because most of the opinions you expressed so far are usually
symptomatic from a Java exposure. FWIW, the fact that you "never used
Java for any public project" doesn't contradict anything of my above
writing.

Quote:

I fail to see how your view of "data = state / methods = behaviour" or
your advice to "make all data attributes private" comes from experience
writing Python code.

Quote:

There's only
so much books can do when it comes to designing robust software in
practice.

Indeed.

Quote:

But for a lot of people over here who claim they've been
programming for X number of years, some of them certainly do need to
hit the books again. I don't believe I spent an inordinate amount of
time explaining state and behavior or the benefits or techniques for
reducing coupling or why anyone would need accessors, among other
things.

Do you really believe you taught me anything about these topics ?

Quote:

Thanks to the people who exposed me to Python's properties.

The problem is that you definitively *failed* to understand how to use
them (or actually how to *not* use them when not needed).

Sure, if it makes you feel better.

Alas, not. Seeing someone inflicting himself pain because of misbelief
or misunderstanding does not "make me feel better". Too bad you take it
this way.

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"

Diez B. Roggisch
*nix forums Guru

Joined: 20 Feb 2005
Posts: 882

Posted: Thu Jul 20, 2006 3:50 pm Post subject: Note

Re: Accessors in Python (getters and setters)

Quote:

Neat! That slipped my attention over all this noisy and pointless
discussion...

Regards,

Diez

mystilleef@gmail.com
*nix forums beginner

Joined: 11 Oct 2005
Posts: 46

Posted: Thu Jul 20, 2006 3:59 pm Post subject: Note

Re: Accessors in Python (getters and setters)

Bruno Desthuilliers wrote:

Quote:

mystilleef wrote:
Bruno Desthuilliers wrote:

(snip)
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.

doh :(

Let's talk about psychorigid mindset...

Thanks, I'm insane.

You say so.

(snip)
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?

To allow attribute syntax when you really have computation behind. Which
1/ let you start with the simplest case (a simple attribute) and change
your mind latter
2/ offer the possibility to use an attribute syntax (instead of a method
call syntax) when it seems more natural.

Right, and what I'm I trying to do again?

Write Java in Python.

Dude, I haven't written more than "Hello World" programs in Java. I
__don't__ have a strong Java background.

Quote:

point 2 : so anyone *can* "illegimately tampering with an object's
internal data" at will.

And this is robust how?

You can do just the same in Java or C++.

OMG!

It's common knowledge.

I ask how your solution is robust, and you go off talking about Java
and C++. Quit turning this into a language pissing contest. The hell I
care what Java or C++ does.

Quote:

If you say so.

Quote:

Chosen what answer? First of all, I have no idea what you are trying to
do. Secondly, I wouldn't code like that. So asking for my input on
some code that I believe has no purpose is irrelevant. In your class,
Complicated, why are your accessors private? Why is the attribute the
accessors are modifying public? In your second class, can data afford
to be modified by anyone? Does doing that cause any corruption, bugs,
indiscrepancies in the system? You can't just throw code at me, out of
context, and tell me to choose which is better. It's just premature.

Quote:

Doesn't that fall under the "DO NOT DO THIS AT HOME KIDS" in the FAQ
section or somewhere?

Quote:

to make yourself feel happy.

yes, of course, I need this to feel happy. Doh :(

Sure Python lets your do that,
but that's an implementation detail almost all Python developers could
give a damn about. How many times do I have to tell you I don't care
for latent semantic implementation details of Python? Anybody who does
what you just did should be laughed at derisively and ignored.

Believe it or not, but there are times someone may have a perfectly
valid reason to do so (probably not with your example, but that's
another point).

I have never seen any Python code do that. I will certainly reject code
like that in my project. But if people do it without any ill effects,
good for them. I don't do it, I don't know any Python developer that
does.

Quote:

But I
don't have time to deal with fantasy and unreleastic theories.

blah blah.

As I told you, there's no cure for idiocy.

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.

And what if you want to change 'buffer_is_active' to 'is_active' ?

But I don't want to. I wanna change implementation not interface.

Changing implementation from direct attribute access to property doesn't
require changing the interface, so there's no reason to use a property
for simple read/write access. period.

There is. The name issues already afore-mentioned elsewhere.

Quote:

You enjoy pointing fingers, don't you?

Quote:

guess
who's gonna get the emails and bug reports? That's right you!

And ?

You have to investigate it?

Quote:

And that
is after hours of trying to reproduce the bug on your system
unsuccessfully

If the app runed fine and all of a sudden starts to crash, I'll suspect
something specific to the user system.

There you go again pointing fingers. It has to be the stupid idiotic
users fault.

Quote:

because you don't have the bloody plug-in installed and
they user doesn't know a random plug-in he downloaded is the root of
the problem.

"Hi Mr User... Just a question about your problem : did you change
anything in your system recently ? Like installing a new plugin ?"

Yeah, now you have 20/20 hindsight.

Quote:

Because in the real
world when your program is buggy, you get bug reports, nasty emails
among other forms of ridicule.

So you see receiving a bug report as a form of ridicule ?

Yes, it can be.

I definitively give up trying to understand you.

I guess you haven't got bug reports that make you feel like s**t. Only
to find out the problem actually has nothing to do with your app.

Quote:

Now FWIW, I have lot of python apps in production, very few bug reports
[1], and none of them being the result of the problem you seems to fear
that much.

Good for you! I'm sure you are brilliant programmer.

I'm not.

[1] The very first release of one of them is in production for more than
6 monthes now, is daily used by a dozen non-computer-savy users, and not
a *single* bug report - actually, the only return we had is "it's
perfect, it works like a charm, and we have some other stuff for you guys"

My users are not just end users they are also developers.

Developpers are supposed to know enough to fill in useful bug reports...
and possibly do some prior research on the problem by themselves.

Developers extend your application in ways you hadn't originally
anticipated, thus exposing bugs. And no, it's not the developers fault.
I know that's where you are going. There are several reasons why this
can happen, including me not protecting object's state properly. But
we've already been through all that to no avail.