Class design (information hiding)
Alexander Eisenhuth
I'm wodering how the information hiding in python is ment. As I understand there
doesn't exist public / protected / private mechanism, but a '_' and '__'
naming convention.
As I figured out there is only public and private possible as speakin in "C++
manner". Are you all happy with it. What does "the zen of python" say to that
design? (protected is useless?)
class A:
def __init__(self):
self.__z = 1
self._z = 2
self.z = 3
def _getX(self):
return "X"
def __getY(self):
return "Y"
def doAnything(self):
print self.__getY()
class B(A):
def __init__(self):
A.__init__(self)
print dir (self)
>>> b = B()
['_A__getY', '_A__z', '__doc__', '__init__', '__module__', '_getX', '_z',
'doAnything', 'z']
I was a bit surprised about '_A__getY' and '_A__z'.
What would you say to a C++ Programmer about class interfaces in big Python
systems? What is the idea behind the _ and __ naming. Use or don't use '_'
methods ? (As Designer of the software, as Programmer of the software)
Regards Alexander
Wildemar Wildenburger
> As I figured out there is only public and private possible as speakin in
> "C++ manner". Are you all happy with it. What does "the zen of python"
> say to that design? (protected is useless?)
>
>>> import this
>
> class A:
> def __init__(self):
> self.__z = 1
> self._z = 2
> self.z = 3
> def _getX(self):
> return "X"
> def __getY(self):
> return "Y"
> def doAnything(self):
> print self.__getY()
>
>
> class B(A):
> def __init__(self):
> A.__init__(self)
> print dir (self)
> >>> b = B()
> ['_A__getY', '_A__z', '__doc__', '__init__', '__module__', '_getX',
> '_z', 'doAnything', 'z']
>
> I was a bit surprised about '_A__getY' and '_A__z'.
>
In what way exactly? "__*"-type methods are meant to be private to the
exact class they were defined in, so thats why you get these names
prefixed with "_A__". If you're confused why that happens at all, look
for "name mangling".
> What would you say to a C++ Programmer about class interfaces in big
> Python systems? What is the idea behind the _ and __ naming. Use or
> don't use '_' methods ? (As Designer of the software, as Programmer of
> the software)
>
Don't worry about information-hiding too much. If anyone is determined,
they can get at any information they want. You should just rely on
people not directly using a single-underscore method; thats how python
does it: trust instead of force.
Use the double underscore technique only when you *need* it, that is,
you don't want a method to be overridden by a subclass -- for whatever
reason that might be. Generally you can just forget about this type of
methods.
/W
Bruno Desthuilliers
> Hi all,
>
> I'm wodering how the information hiding in python is ment.
Conventions...
> As I
> understand there doesn't exist public / protected / private mechanism,
> but a '_' and '__' naming convention.
Yes.
> As I figured out there is only public and private possible as speakin in
> "C++ manner".
Nope. It's either 'interface' (no leading underscore), 'implementation'
(single leading underscore), 'implementation with some protection
against accidental overriding' (two leading underscores).
> Are you all happy with it.
Can't speak for others, but as far as I'm concerned, I'm perfectly happy
with this.
>
> class A:
> def __init__(self):
> self.__z = 1
> self._z = 2
> self.z = 3
> def _getX(self):
> return "X"
> def __getY(self):
> return "Y"
> def doAnything(self):
> print self.__getY()
>
>
> class B(A):
> def __init__(self):
> A.__init__(self)
> print dir (self)
> >>> b = B()
> ['_A__getY', '_A__z', '__doc__', '__init__', '__module__', '_getX',
> '_z', 'doAnything', 'z']
>
> I was a bit surprised about '_A__getY' and '_A__z'.
It's documented.
(snip)
> What is the idea behind the _ and __ naming.
cf above.
You may also want to read this - while C++ is not Java either, some
advises may still apply:
http://dirtsimple.org/2004/12/python-is-not-java.html
HTH
Gregor Horvath
>
> I'm wodering how the information hiding in python is ment. As I
> understand there doesn't exist public / protected / private mechanism,
> but a '_' and '__' naming convention.
>
> As I figured out there is only public and private possible as speakin in
> "C++ manner". Are you all happy with it. What does "the zen of python"
> say to that design? (protected is useless?)
My favourite thread to this FAQ:
Greg
Alexander Eisenhuth
> Nope. It's either 'interface' (no leading underscore), 'implementation'
> (single leading underscore), 'implementation with some protection
> against accidental overriding' (two leading underscores).
What do you mean with 'implementation'? What does it express?
Marc 'BlackJack' Rintsch
I guess he meant 'implementation detail', i.e. someone other then the
author of the class should not use until he really knows the
implementation and that this all might change without notice in the next
release.
Ciao,
Marc 'BlackJack' Rintsch
Bruno Desthuilliers
The fact that a given attribute (or method - which are just callable
attributes FWIW) is an implementation detail, and not a part of the
class interface.
Alex Martelli
Why, thanks for the pointer -- I'm particularly proud of having written
"""
The only really workable way to develop large software projects, just as
the only really workable way to run a large business, is a state of
controlled chaos.
"""
*before* I had read Brown and Eisenhardt's "Competing on the Edge:
Strategy as Structured Chaos" (at that time I had no real-world interest
in strategically managing a large business -- it was based on mere
intellectual curiosity and extrapolation that I wrote "controlled chaos"
where B & E have "structured chaos" so well and clearly explained;-).
BTW, if you want to read my entire post on that Austrian server, the
most direct URL is
<http://groups.google.at/group/comp.lang.python/msg/b977ed1312e10b21?>
...
Alex
Gregor Horvath
>
> Why, thanks for the pointer -- I'm particularly proud of having written
> """
> The only really workable way to develop large software projects, just as
> the only really workable way to run a large business, is a state of
> controlled chaos.
> """
Yes, indeed a good saying.
The problem is that we do not understand those complex systems, despite
the fact that some megalomaniacal people think they do.
Declaring a method as private, public or protected assumes that the
author fully understands the uses of this class by other programmers or
even himself later on.
But if the software is complex enough, chances are good that he does
*NOT* understand it fully at the time he writes "Protected".
Programming means attempting. Attempt implies failure. Flexible systems
that are built for easy correction are therefore superior.
Greg