Accessors in Python (getters and setters)

A

Ant

Ed said:
Java does not allow access to private members via reflection.

Yes it does. You can call setAccessible(true) on the Method object to
override the privateness.
 
G

Gerhard Fiedler

"Code generation" springs into my mind. IMO, if the code needs to be
generated, the language is not sufficiently advanced.

Isn't that just a question of level? I'm sure there are editors that
generate Python class stubs, GUI builders that generate Python GUI
frameworks, and so on. Nothing needs to be generated, but some things are
more convenient to write (for some people; convenience is quite subjective)
using generators.

Gerhard
 
B

Bruno Desthuilliers

Tobias Brox a écrit :
[Jason]
Nothing like being forced to write getters and setters in C++/Java
before you feel like shooting your source code. Please don't bring
this code-rage into Python.


"Code generation" springs into my mind. IMO, if the code needs to be
generated, the language is not sufficiently advanced.
OTOH, most decorators and metaclass hacking is somehow code generation -
but hopefully not at the source code level...
 
D

danielx

Bruno said:
No, I meant find and grep.

Yeah, fine - as long as your pretty sure the same name is not used in
other contexts in any of the source files...

I think that was the original point about find/replace: it can be
really hard to automate a name change, because changes might occur that
you didn't intend; whereas, doing things by hand lacks consistency.

My solution is to use emacs' query-replace (which you can invoke with
M-%). It will find quicly and accurately, but I ultimately hold the key
to whether something gets replaced or not.
 
M

mystilleef

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

You make the attribute private/protected.
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)

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
 
M

mystilleef

Steve said:
mystilleef wrote, making me somewhat tired of his/her repeated inability
to get what's being said [sigh]:This makes it somewhat obvious that you don't appear to fully understand
the concept of coupling as applied to software systems.
Riiiiight!
If you implement an accessor to change a class's instances' states,
surely something has to call that accessor. You seem to be implying that
such calls can only be made from within other methods of the same
object, which (if true, which it isn't) would tend to leave each class
in a vacuum where nothing else can affect its instances.

Of *course* objects are subject to external influences: since you like
the concept of coupling, how else could different components be coupled
at all?

I gave the solution earlier. In well designed systems objects should be
responsible for updating their state themselves. In essence, objects
should learn to mind their own business. There will be some form of
coupling, but it should be minimal. Preferably the only coupling
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
completely replace modules and objects with new ones without breaking
the whole system. If you are dealing with large source code, this is a
no brainer. And if you put a little effort into to it, you can create
objects that know when to initialize and destroy themselves as well as
update their states automatically. Welcome to event based programming.

(snip)
Well you should know, you're the one who wants to hang on to it. So
please enlighten us, what is this source of knowledge that appears to
contradict sound computer science?

High coupling is bad. Exposing critical states of an object is bad. Any
decent computer science book will tell you that.
Whereas you appear to feel that there can be no possibility if a crash
because someone calls thing.is_active(True), and yet you repeatedly fail
to demonstrate the difference. Which is why this thread has been so
mind-numbingly long. As is pointed out AGAIN here:
Perhaps so, but you still refuse to explain why it's better, when all
you need to do is read or write the value of an instance's attribute, to
define accessor methods to do it, introducing unnecessary (in Python)
overhead in the process.

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.
Am I the only one here who has lost track of this "'tis/'tisn't" stuff?

In which case you write correct software and provide it with a thorough
set of tests to allow you to modify it without worrying too much about
breakage. Attribute access is part of an object's API just like method
calls are.

Or I use accessors. Because I write tests doesn't mean third parties do
so, or even uphold the practice.
You seem to think that every ill in software design can be legislated
away by strangling design freedom with specific rules. I am afraid that
experience will teach you this is far from the case: go look at the way
that the "bondage" languages that use static typing (like Java and C++)
still fail to impose the required typing discipline on a determinedly
incompetent user.

Well I disagree. I used to share you mentality until I started managing
large source code. You need rules if you don't want your project to
collaspe under anarchy. And it is not until other people start using
your software in ways you never imagined that you realize the
importance of designing robust implementations upfront. When I wrote
less than a 1000 lines of Python code, I didn't care for
properties/accessors/public/private states or whatever. And I drank all
the Python philosophy cool aid I could get. But when you begin to get
emails about bugs in your software due to a third party inadvertently
changing states you never bothered to hide to begin with, then the
wisdom behind careful upfront planning begins to make sense.
As has already been said, the Python philosophy is to provide the
features that "consenting adults" (i.e. programmers who know what they
are doing) can use most effectively to produce complex software systems
to reasonable deadlines. Unfortunately not all the knowledge required to
do this is readily available in books; the rest must come from experience.

That's all fine and dandy in the fantasy world. In the real world,
consenting adults do stupid things, and if I can prevent them from
doing it, especially when it affects me, I bloody well will.
 
D

Dennis Lee Bieber

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?

The "," is what allows for the "too" to have independent meaning ("also"
could have been use, and maybe with more emphasis:

... don't need, ALSO?

--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/
 
D

Dennis Lee Bieber

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...
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/
 
M

Marc 'BlackJack' Rintsch

mystilleef said:
Huh? What are properties for then?

To have a tool to change the default accessor into something more
complicated, a calculated attribute, without the need to change the API.
And this is robust how?

That's as robust as the consenting adults that use that code. And as
robust as Java where you can get at private attributes via reflection and
C++ where you can simply define private as public.
You can't be serious. Please tell me you are joking.

No he's not joking. If programmers don't read the "stop here, this is
internal" signs and carelessly change states then there's a much bigger
problem than access control. The problem is with the programmer, not the
language.
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!

No you don't.

obj = Robust()
obj._Robust__is_active = 42

The name munging is not meant to provide access control but to avoid name
clashes when dealing with deep inheritance hierarchies or mixin classes.

A pythonista would just call the attribute `_is_active` and rely on the
common sense of other programmers not to play with it at will.
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.

If it's called `_is_active` then the access to it should not be spread
over 27000 lines. You don't access attributes not belonging to the API
from everywhere in the code base. If you do, you are a bit careless as a
programmer, don't you think?
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."

The name `_is_active` tells that it's not API. If the naïve third party
does not respect this than it's on its own. The solution is indeed to
tell that to them because otherwise they will get into trouble when they
continue to program in Python where this is the common way to make things
"private".
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.

You shouldn't waste your time with Python then. The language is obviously
not "bondage" enough for your needs.

Ciao,
Marc 'BlackJack' Rintsch
 
S

Steve Holden

Dennis said:
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.


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.


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




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
 
S

Steve Holden

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.
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.
Thanks to the people who exposed me to Python's properties.

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

regards
Steve
 
M

mystilleef

Steve said:
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()

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

some_robust.buffer_is_active

is appropriate.
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.
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.
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.

And mine are based on future engineering predictions? Okay, one day I
shall see the light.
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.
 
B

Bruno Desthuilliers

mystilleef said:
You make the attribute private/protected.

doh :(

Let's talk about psychorigid mindset...
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.
And this is robust how?

You can do just the same in Java or C++.
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.
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.
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

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' ?
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.
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"

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.
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
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.
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.
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).
 
B

Bruno Desthuilliers

Dennis said:
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.
 
G

Gerhard Fiedler

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
 
S

Steve Holden

Gerhard said:
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
 
D

Diez B. Roggisch

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.


To second that:

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

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


Diez
 
B

Bruno Desthuilliers

mystilleef wrote:
(snip)
__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)
 
B

Bruno Desthuilliers

Gerhard Fiedler wrote:
(snip)
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)
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.
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).
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top