Russ P. a écrit :
On Jun 5, 4:53 am, Bruno Desthuilliers <bruno.
[EMAIL PROTECTED]> wrote:
Russ P. a écrit :
Given your very recent discovery of what 'dynamic' *really* means in
Python (like, for exemple, dynamically adding / replacing attributes -
including methods - on a per-class or per-instance basis), possibly, yes.
My "very recent" discovery? Funny, I thought I knew that several years
ago.
Looks like I mistook your
"""
I also realize, by the way, that Python allows a client of a class to
define a new class member from completely outside the class
definition
"""
as "I just realized (...)"
Sorry for having read too fast.
I also realize, by the way, that Python allows a client of a class to
define a new class member from completely outside the class
definition. Obviously, that cannot be declared private.
Why so ?
Why should the client of a class not be able to declare a *private*
member of the class? You're kidding, right?
I'm dead serious. I often add implementation attributes to either a
class or an instance. These *are* implementation parts, not API.
Do you mind if I tell you
how to arrange the furniture in your bedroom?
I must be a bit dumb, but I don't see how human interaction problems
relate to enforced access restriction in an OO programming language.
But if the
same identifier is already declared private within the class, than the
new definition should not be allowed (because it would defeat the
whole idea of "private" class members).
Why so ?
Metaprogramming (including monkeypatching) is part of the pythoneer's
toolbox, and while it's not something to use without pretty good
reasons, it has many times proven to be a real life saver. In languages
not allowing it, the solutions to the class of problems easily solved by
monkeypatching happens to be at best a kludge, at worst plain
unsolvable, at least without too much effort to be even worth it. Your
above proposition would arbitrarily make possible and useful things
either uselessly complicated or near impossible.
For the record, I have made it abundantly clear that I don't think
Python should not have as rigorous an encapsulation regime as C++ or
Java. The worst that could happen with my proposition is that you
would need to use a "mangled" name to access private data or methods.
That's already the case - when you use __name_mangling. And if there's
no effective access restriction, then what the point of having this
'priv' keyword ?
But you will be using the name many times, you can reassign your own
name, of course, so the mangled name need not appear more than once
where it is needed.
Once again, I just don't see the point. Either you want effective access
restriction in Python, or you don't. And if you don't, what would this
'priv' keyword be useful to ?
--
http://mail.python.org/mailman/listinfo/python-list
