Class Variable Question

[Ken Seehof]

This is interesting in that I often want to do the exact opposite in
C++.  That is, I want to add extra data to an existing object,
especially when this is -not- intended by the author of the original
code, who neglected to add in a "void *pUserData" for me.

In the general case, the ability to add arbitrary data to an object
is a convenience, not a flaw.  Bob Kline's excellent example code
demonstrates that you can protect an object from 'misuse' if you
need to in some special circumstance.  It would, of course, be
foolish to add this code to every class in order to repair some kind
of perceived flaw in python.

I think people tend to be confused about issues around late
binding and strong vs. weak typing (constraining the set of writable
members is a form of strong typing).  C++ is strongly typed largely
because of the way data is stored in memory.  The compiler must
know essentially all type information at compile time.  Strong typing
prevents a wide range of bugs in which there is a mismatch between
the compilers idea of how things are stored in memory and the way
the program at runtime thinks things are stored in memory.  The
more strong typing C/C++ gets, the better the protection against
these kinds of bugs.  Weak typing within C/C++ (e.g. arbitrary
typecasting of void pointers) leads to particularly time consuming
and annoying bugs.

These kinds of bugs do not occur in python, so the benifit of strong
typing is dubious.  Of course there are some simple bugs that strong
typing could prevent in python, but such bugs aren't nearly so time
consuming, and they are of the same level of difficulty as normal
everyday errors that can't be prevented in any language.

You can always protect against certain bugs by reducing the
expressiveness and flexibility of a language, but that's not always
a good idea.  For example, by removing the addition operator, we
can prevent errors such as y = x+3 when we really mean y = x+2.

Another common fallicy made by people talking about type safety
is that the Author of a class library or API is always an order of
magnitude more competent that the user of the class, so if the Author
of the class didn't think of it, it should not be allowed.

Bob Kline <bkline at rksystems.com> wrote:
> On Mon, 9 Apr 2001, Alex Martelli wrote:
>
> > "Robert Johnson" <rjohnson at exotic-eo.com> wrote in message
> > news:3ad1c7e9$0$196$e2e8da3 at nntp.cts.com...
> >
> > > Is there a way to prevent this so users cannot add variables?
> >
> > Nope (how would one distinguish 'users' from other pieces
> > of code for this purpose?).  You can wrap objects up into
> > a Bastion if you have security worries.
> >
> > > It seems to me that the user could just override a class with
> > > unrelated data.
> >
> > Sure, just like he could say x=y-z when actually meaning x=y+z, and
> > a zillion other horrible programming errors.
> >
> > Hopefully the user will then run some _tests_ (what other ways would
> > you suggest for the "plus oops I meant minus" kind or errors to be
> > caught...?), fix the mistakes he then finds as a result of his
> > testing, and have code with fewer errors -- including code free from
> > accidental, erroneous rebindings of all kinds.
>
> Ah, you have to love these "You-mean-you-actually-put-bugs-in-your-
> software-that-you-have-difficulty-finding?" responses, especially when
> the alternating refrain from Python fans is "Why on earth would you want
> to use a language which doesn't eliminate memory management bugs for
> you?"
>
> And now for something completely different.  Here's a (possibly) more
> helpful response.  You might want to try something along these lines:
>
> $ cat SafeClass.py
> class SafeClass:
>     members = ('foo','bar')
>     def __init__(self):
>         self.foo = 42
>         self.bar = 'floccinaucinihilipilification'
>     def __setattr__(self, name, value):
>         if name not in SafeClass.members:
>             raise "%s is not a member of SafeClass" % name
>         self.__dict__[name] = value
> $ python
> Python 1.5.2 (#1, Aug 25 2000, 09:33:37)  [GCC 2.96 20000731
(experimental)] on linux-i386
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> from SafeClass import SafeClass
> >>> sc = SafeClass()
> >>> sc.foo = 43
> >>> sc.fud = 44
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
>   File "SafeClass.py", line 5, in __setattr__
>     raise ("%s is not a member of SafeClass" % (name,))
> fud is not a member of SafeClass
>
> As you can see, this approach needs another five lines in the class
> definition, and of course the members list would have to be maintained,
> but the example demonstrates that the correct answer to your question
> ("Is there a way to prevent this so users cannot add variables?") is
> actually "Yes."  The approach doesn't prevent intentional undermining of
> the safety measure, but it will catch the sorts of mistakes you're
> asking about.
>
> Hope this helps.
>
> --
> Bob Kline
> mailto:bkline at rksystems.com
> http://www.rksystems.com
>
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20010409/4ad770b9/attachment.html>