Russ P. a écrit :
On Jun 6, 8:25 am, Bruno Desthuilliers <bruno.
[EMAIL PROTECTED]> wrote:
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.
If a client accesses a data member of a class,
Please stop thinking in C++. This is Python, and all you have are
attributes. Whether they're callable of not doesn't change much here.
then by definition that
member is not really private,
Who cares about it being "private" ? The important point is that it's
*implementation*, not *interface*.
so letting the client create a new data
member and declare it as private seems a bit silly to me.
There are two ways to decorate a class or instance object (nb: Python's
classes are objects too): the "static" way where you wrap the object in
a decorator class or instance and use delegation, and the "dynamic" way
where you just modify the original class or object at runtime. The fact
that an attribute is added (or replaced) outside the class statement
doesn't mean it has to be part of the interface. You sometime have
pretty legitimate reason to modify the implementation at runtime.
Actually,
just letting the client create the new data member, private or not,
seems like a bit of a stretch to me, but I'll leave that be.
You're way too much in the Java/C++ way of thinking.
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 ?
In the end, I suppose it boils down to aesthetics and personal
preference.
The leading-underscore convention bothers me for two reasons: (1) like
the OP, I don't like the way it makes my code look, and (2) it is a
signal to a person reading the code, but it has no actual effect in
the interpreter.
Indeed. The target of the signal is definitively the person reading the
code.
I think the concept of private data and methods is important enough to
be implemented with more than just a tacky naming convention.
The concept of "private" attributes is not important. What's important
is the concept of implementation attributes.
That is
why I suggested the "priv" keyword. At the same time, I realize that
people will occasionally be frustrated if they are rigorously denied
access to all private data, which is why I suggested an "indirect"
method of access through mangled names.
We already have all this. Either you want language-enforced access
restriction - then you might be happier with another language - or you
just want to have a clear way to know whether an attribute is part of
the API or not - in which case a naming convention is not only enough,
but even better.
You can argue that such indirect access defeats the whole idea of
private data, but at least it alerts the client to the fact that he
(or she or it) is accessing private data
So does the naming convention, with much less work.
-- and it does so without
using Hungarian notation.
I wouldn't label this "hungarian notation" - or at least, not the way
"hungarian notation" is now commonly understood.
I would let the "priv" keyword also be used for data or functions at
file scope. It just seems logical to me. Again, some name mangling
convention could be concocted for those who think they really need
access.
Actually, the whole objection to denied access baffles me a bit.
Free your mind from the very peculiar, restricted and IMHO braindead
conception of "OO" they taught you with Java and C++. Python is older
than Java, it's by now a very very commonly used language on all major
platforms, and experience prooves that you just don't need anything more
than a simple naming convention.
Does
anyone object to not having access from outside a function to local
variables within the function? I doubt it. The other thing is that the
vast majority of Python software, I would guess, is provided with
source code. How many Python applications or libraries are provided
without source code? If you have the source code, you can obviously
just delete the "priv" keyword anywhere or everywhere it appears.
Yes, fine. And then have to maintain a fork of the source code, and
distribute it with the application. Honking great idea. doh :-(
And
if you have a major client who insists on access to all the internals,
just delete all occurrences of "priv" before you ship the code (or
don't use it to start with).
Or don't even bother about this useless access restriction stuff. Which
will save you quite a lot of valuable time.
--
http://mail.python.org/mailman/listinfo/python-list
