Movatterモバイル変換

Class Variable Question

• Previous message (by thread):Class Variable Question
• Next message (by thread):Class Variable Question
• Messages sorted by:[ date ][ thread ][ subject ][ author ]

This is interesting in that I often want to do the exact opposite inC++.  That is, I want to add extra data to an existing object,especially when this is -not- intended by the author of the originalcode, who neglected to add in a "void *pUserData" for me.In the general case, the ability to add arbitrary data to an objectis a convenience, not a flaw.  Bob Kline's excellent example codedemonstrates that you can protect an object from 'misuse' if youneed to in some special circumstance.  It would, of course, befoolish to add this code to every class in order to repair some kindof perceived flaw in python.I think people tend to be confused about issues around latebinding and strong vs. weak typing (constraining the set of writablemembers is a form of strong typing).  C++ is strongly typed largelybecause of the way data is stored in memory.  The compiler mustknow essentially all type information at compile time.  Strong typingprevents a wide range of bugs in which there is a mismatch betweenthe compilers idea of how things are stored in memory and the waythe program at runtime thinks things are stored in memory.  Themore strong typing C/C++ gets, the better the protection againstthese kinds of bugs.  Weak typing within C/C++ (e.g. arbitrarytypecasting of void pointers) leads to particularly time consumingand annoying bugs.These kinds of bugs do not occur in python, so the benifit of strongtyping is dubious.  Of course there are some simple bugs that strongtyping could prevent in python, but such bugs aren't nearly so timeconsuming, and they are of the same level of difficulty as normaleveryday errors that can't be prevented in any language.You can always protect against certain bugs by reducing theexpressiveness and flexibility of a language, but that's not alwaysa good idea.  For example, by removing the addition operator, wecan prevent errors such as y = x+3 when we really mean y = x+2.Another common fallicy made by people talking about type safetyis that the Author of a class library or API is always an order ofmagnitude more competent that the user of the class, so if the Authorof 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>

• Previous message (by thread):Class Variable Question
• Next message (by thread):Class Variable Question
• Messages sorted by:[ date ][ thread ][ subject ][ author ]