yes, with metaclasses (was Re: Read-only class definitions?)

[Alex Martelli]

sismex01 at hebmex.com wrote:
        ...
> There, you seem to be trying to prevent malicious users from
> mangling your classes; I don't think it can be done with
> Python, since there's no artificial restrictions (a'la
> "private" and "protected" class members) placed on the

Right, there aren't (unless perhaps you run user code in
restricted-mode, in which case you may gain some measure
of control -- but there may be ways to subvert such
security attempts).

> language, but then, even in those that have such artificial
> restrictions you can do that; just a reminder of how to

Not necessarily -- in Java, if you control the JVM, and
it's free of any exploitable security weaknesses whatever,
you MAY be able to prevent user-programs from doing what
you don't want them to do.

Why one would want to consider users of your libraries
as being BY DEFAULT adversaries devoted to the task of
breaking them, I'm not sure, but it seems to be a widespread
mentality.  In general, if your libraries' users are known
to be inimical and bent on destruction, Python may not be
the best language for you to use, I suspect.

> completely expose any hidden functionality on a C++ class:
> 
> #define protected public
> #define private public
> #include <header-with-class-to-rape.h>

That depends on the C++ implementation.  In IBM's "Direct
to SOM" C++ compilers, as I recall, this would make the
.h you're including describe a completely different class
from the one you're then going to try to like, with a
different CRC signature and everything, so that such a
program just wouldn't link.  Most C++ compilers don't seem
to go even to the trouble of decorating private and public
members differently, which would be a rather trivial way
of fighting against this trick -- presumably there isn't
much demand for such help, in keeping with C++'s purpose
for private/protected, which, like Python's conventions,
is meant to protect against *accidents*, not malice.


> So in fact, what you should do is document the expected
> interfase and behaviour, and warn about mangling the object's
> insides. It's up to the individual developer to behave in
> a responsible manner when using it.

Yes, but there's no harm in giving your users a little help
detecting accidental misuse -- as long as that doesn't
interfere with normal, deliberate ways to use your library,
of course.


Alex