<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META content="MSHTML 5.00.3105.105" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>This is interesting in that I often want to do the
exact opposite in<BR>C++. That is, I want to add extra data to an existing
object,<BR>especially when this is -not- intended by the author of the
original<BR>code, who neglected to add in a "void *pUserData" for me.<BR><BR>In
the general case, the ability to add arbitrary data to an object<BR>is a
convenience, not a flaw. Bob Kline's excellent example
code<BR>demonstrates that you can protect an object from 'misuse' if you<BR>need
to in some special circumstance. It would, of course, be<BR>foolish to add
this code to every class in order to repair some kind<BR>of perceived flaw in
python.<BR><BR>I think people tend to be confused about issues around
late<BR>binding and strong vs. weak typing (constraining the set of
writable<BR>members is a form of strong typing). C++ is strongly typed
largely<BR>because of the way data is stored in memory. The compiler
must<BR>know essentially all type information at compile time. Strong
typing<BR>prevents a wide range of bugs in which there is a mismatch
between<BR>the compilers idea of how things are stored in memory and the
way<BR>the program at runtime thinks things are stored in memory.
The<BR>more strong typing C/C++ gets, the better the protection against<BR>these
kinds of bugs. Weak typing within C/C++ (e.g. arbitrary<BR>typecasting of
void pointers) leads to particularly time consuming<BR>and annoying
bugs.<BR><BR>These kinds of bugs do not occur in python, so the benifit of
strong<BR>typing is dubious. Of course there are some simple bugs that
strong<BR>typing could prevent in python, but such bugs aren't nearly so
time<BR>consuming, and they are of the same level of difficulty as
normal<BR>everyday errors that can't be prevented in any language.<BR><BR>You
can always protect against certain bugs by reducing the<BR>expressiveness and
flexibility of a language, but that's not always<BR>a good idea. For
example, by removing the addition operator, we<BR>can prevent errors such as y =
x+3 when we really mean y = x+2.<BR><BR>Another common fallicy made by people
talking about type safety<BR>is that the Author of a class library or API is
always an order of<BR>magnitude more competent that the user of the class, so if
the Author<BR>of the class didn't think of it, it should not be
allowed.<BR><BR>Bob Kline <<A
href="mailto:bkline@rksystems.com">bkline@rksystems.com</A>> wrote:<BR>>
On Mon, 9 Apr 2001, Alex Martelli wrote:<BR>><BR>> > "Robert Johnson"
<<A href="mailto:rjohnson@exotic-eo.com">rjohnson@exotic-eo.com</A>> wrote
in message<BR>> > <A
href="news:3ad1c7e9$0$196$e2e8da3@nntp.cts.com">news:3ad1c7e9$0$196$e2e8da3@nntp.cts.com</A>...<BR>>
><BR>> > > Is there a way to prevent this so users cannot add
variables?<BR>> ><BR>> > Nope (how would one distinguish 'users'
from other pieces<BR>> > of code for this purpose?). You can wrap
objects up into<BR>> > a Bastion if you have security worries.<BR>>
><BR>> > > It seems to me that the user could just override a class
with<BR>> > > unrelated data.<BR>> ><BR>> > Sure, just like
he could say x=y-z when actually meaning x=y+z, and<BR>> > a zillion other
horrible programming errors.<BR>> ><BR>> > Hopefully the user will
then run some _tests_ (what other ways would<BR>> > you suggest for the
"plus oops I meant minus" kind or errors to be<BR>> > caught...?), fix the
mistakes he then finds as a result of his<BR>> > testing, and have code
with fewer errors -- including code free from<BR>> > accidental, erroneous
rebindings of all kinds.<BR>><BR>> Ah, you have to love these
"You-mean-you-actually-put-bugs-in-your-<BR>>
software-that-you-have-difficulty-finding?" responses, especially when<BR>>
the alternating refrain from Python fans is "Why on earth would you want<BR>>
to use a language which doesn't eliminate memory management bugs for<BR>>
you?"<BR>><BR>> And now for something completely different. Here's a
(possibly) more<BR>> helpful response. You might want to try something
along these lines:<BR>><BR>> $ cat SafeClass.py<BR>> class
SafeClass:<BR>> members =
('foo','bar')<BR>> def
__init__(self):<BR>> self.foo
= 42<BR>> self.bar =
'floccinaucinihilipilification'<BR>> def
__setattr__(self, name,
value):<BR>> if name not in
SafeClass.members:<BR>>
raise "%s is not a member of SafeClass" %
name<BR>> self.__dict__[name]
= value<BR>> $ python<BR>> Python 1.5.2 (#1, Aug 25 2000, 09:33:37)
[GCC 2.96 20000731<BR>(experimental)] on linux-i386<BR>> Copyright 1991-1995
Stichting Mathematisch Centrum, Amsterdam<BR>> >>> from SafeClass
import SafeClass<BR>> >>> sc = SafeClass()<BR>> >>>
sc.foo = 43<BR>> >>> sc.fud = 44<BR>> Traceback (innermost
last):<BR>> File "<stdin>", line 1, in
?<BR>> File "SafeClass.py", line 5, in
__setattr__<BR>> raise ("%s is not a member of
SafeClass" % (name,))<BR>> fud is not a member of SafeClass<BR>><BR>>
As you can see, this approach needs another five lines in the class<BR>>
definition, and of course the members list would have to be maintained,<BR>>
but the example demonstrates that the correct answer to your question<BR>>
("Is there a way to prevent this so users cannot add variables?") is<BR>>
actually "Yes." The approach doesn't prevent intentional undermining
of<BR>> the safety measure, but it will catch the sorts of mistakes
you're<BR>> asking about.<BR>><BR>> Hope this helps.<BR>><BR>>
--<BR>> Bob Kline<BR>> <A
href="mailto:bkline@rksystems.com">mailto:bkline@rksystems.com</A><BR>> <A
href="http://www.rksystems.com">http://www.rksystems.com</A><BR>><BR>><BR>><BR>>
--<BR>> <A
href="http://mail.python.org/mailman/listinfo/python-list">http://mail.python.org/mailman/listinfo/python-list</A><BR>><BR></FONT></DIV></BODY></HTML>