On 2 Oct 2005 10:31:07 -0700, "El Pitonero" <[EMAIL PROTECTED]> wrote:
>Bengt Richter wrote: >> >> I decided to read this thread today, and I still don't know exactly >> what your requirements are for "private" whatevers. > >No name collision in subclassing. Notice that even if you use > >self._x = 3 > >in a parent class, it can be overriden in a sub-sub-class accidentally. I noticed that, and suggested a GUID-based possible approach ;-) > >> Or maybe, what are your real requirements? >> ;-) > >No need for this type of joke. I'm not sure what you mean, but I meant no offence, just a nudge to refine the requirements statement, and it seems (and I hope) Paul took it that way. [...] >Would any Python programmer trade the benefits of a highly dynamic >language with an unessential feature like Java-style "private" data >members? My guess is not. ISTM it's not a case of either-or here ;-) > >--------------- > >What do I say Java-style "private" is unessential? > >If your Python class/object needs a real Java-style private working >namespace, you have to ask yourself: do the private variables REALLY >belong to the class? Depends on what you mean by "belong" I think ;-) > >In my opinion, the answer is: NO. Whenever you have Java-style private >variables (i.e, non-temporary variables that need to persist from one >method call to the next time the class node is accessed), those >variables/features may be better described as another object, separate >from your main class hierarchy. Why not move them into a foreign worker >class/object instead, and let that foreign worker object hold those >private names, and separate them from the main class hierarchy? (In >Microsoft's jargon: why not use "containment" instead of >"aggregation"?) > >That is, the moment you need Java-style private variables, I think you >might as well create another class to hold those names and >functionalities, since they do not belong to the core functionality of >the main class hierarchy. Whatever inside the core functionality of the >main class, should perhaps be inheritable, sharable and modifiable. Such "another class" is what I was suggesting the automatic hidden creation of when I said """ Alternatively, it might be possible to define (in the metaclass call) __getattribute__ for the class so that it notices when method_foo or method_bar are being accessed to create bound methods, and then bind in a proxy "self" instead that would have self.private_var on its own "self" and delegate public attribute accesses to the normal self. Maybe this could get around byte-code-munging at the cost of easier breakin than via inspect etc., and less run time efficiency. Just musing ... """ What kind of implementation were you thinking of? > >If you use containment instead of aggregation, the chance for name >collision reduces dramatically. And in my opinion, it's the Pythonic >way of dealing with the "private" problem: move things that don't >belong to this object to some other object, and be happy again. > Yes, but how do you propose to implement access the "private" variables without changing the the "spelling" too much? Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list