Re: Class design (information hiding)
Alex Martelli schrieb: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Class design (information hiding)
Gregor Horvath [EMAIL PROTECTED] wrote: Alexander Eisenhuth schrieb: 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: http://groups.google.at/group/comp.lang.python/browse_thread/thread/2c85 d6412d9e99a4/b977ed1312e10b21#b977ed1312e10b21 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Class design (information hiding)
Bruno Desthuilliers schrieb: 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? -- http://mail.python.org/mailman/listinfo/python-list
Re: Class design (information hiding)
On Fri, 07 Sep 2007 15:17:06 +0200, Alexander Eisenhuth wrote: Bruno Desthuilliers schrieb: 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? 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Class design (information hiding)
On 9/7/07, Alexander Eisenhuth [EMAIL PROTECTED] wrote: Bruno Desthuilliers schrieb: 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? Don't touch my _members, they're my private parts! If you do, face the consequences! Again, this isn't enforced by the language (other than the slight name mangling on __names), but a convention that python programmers should adhere to. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Class design (information hiding)
Alexander Eisenhuth schrieb: 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: http://groups.google.at/group/comp.lang.python/browse_thread/thread/2c85d6412d9e99a4/b977ed1312e10b21#b977ed1312e10b21 Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Class design (information hiding)
Alexander Eisenhuth a écrit : 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Class design (information hiding)
Alexander Eisenhuth a écrit : Bruno Desthuilliers schrieb: 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? 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Class design (information hiding)
On 9/7/07, Alexander Eisenhuth [EMAIL PROTECTED] wrote: Hi all, 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?) Strictly speaking, everything is public in python. Members prefixed with __ just get name mangled. But conceptually, yes, there is only public and private members. Information hiding is based on convention, otherwise it would be hard to write debuggers in python, which by definition wants to break the information hiding principle. If you're not writing a debugger, doc generator, or other type of meta level program, follow the conventions of not peeking under the hood. 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'. This is so that in class B, you can also have members called __getY and __z, and they won't interfere with class A (they'll be called _B__getY and _B__z respectively ). What would you say to a C++ Programmer about class interfaces in big Python systems? What is the idea behind the _ and __ naming. As a rough analogy: __name - private _name - protected Use or don't use '_' methods ? (As Designer of the software, as Programmer of the software) I don't know if you're making a distinction here between designer and programmer. Are you meaning implementer of library and user of library? As a user of a library, never ever explicitly call members starting with an underscore. Regards Alexander -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Class design (information hiding)
Hi all, 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Class design (information hiding)
Alexander Eisenhuth wrote: 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?) Ask it yourself: 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 -- http://mail.python.org/mailman/listinfo/python-list
