Waaagh! Python Script won't allow __setitem__
Hi, I've got an object which implements __setitem__ in such a way that it's perfectly safe for use in Python Scripts. Sadly, it seems that Evan's Byte Code hacks won't let me do this :-( Whenever I try to do something like: myobject['fish']=1, I get a traceback like the following: Traceback (innermost last): File E:\Zope\237994~1.0\lib\python\Shared\DC\Scripts\Bindings.py, line 324, in __call__ (Object: ThePythonScript) File E:\Zope\237994~1.0\lib\python\Shared\DC\Scripts\Bindings.py, line 353, in _bindAndExec (Object: ThePythonScript) File E:\Zope\237994~1.0\lib\python\Products\PythonScripts\PythonScript.py, line 330, in _exec (Object: ThePythonScript) (Info: ({'script': <PythonScript instance at 016D16F0>, 'container': <AProduct instance at 01923AA0>, 'traverse_subpath': [], 'context': <AnotherProduct instance at 01888250>}, ({<a dictionary of arguments>},), {}, None)) File Script (Python), line 6, in ThePythonScript File E:\Zope\237994~1.0\lib\python\Products\PythonScripts\zbytecodehacks\VSExec.py, line 429, in __setitem__ TypeError: (see above) Is there any way I can get around this other than renaming __setitem__ to set, which screws up the nice python syntax? cheers, Chris
From: Chris Withers <chrisw@nipltd.com>
I've got an object which implements __setitem__ in such a way that it's perfectly safe for use in Python Scripts. Sadly, it seems that Evan's Byte Code hacks won't let me do this :-(
The only way that the security code can know that your __setitem__ is safe is to rename (or alias) it to __guarded_setitem__. Ditto for other such methods.
If I try and do:
if type(x) == type(0):
Use the Script builtin "same_type" instead: if same_type(x, 0): # Whatever Cheers, Evan @ digicool & 4-am
Evan Simpson wrote:
The only way that the security code can know that your __setitem__ is safe is to rename (or alias) it to __guarded_setitem__. Ditto for other such methods.
Cool :-) Hmmm... I'm sure __getitem__ works okay though ;-)
if type(x) == type(0):
Use the Script builtin "same_type" instead:
if same_type(x, 0): # Whatever
But what's so bad about type()?! cheers, Chris
From: Chris Withers <chrisw@nipltd.com>
But what's so bad about type()?!
When applied to an Extension Class, it gives you access to the actual class, rather than a nice inert type. Cheers, Evan @ digicool & 4-am
Evan Simpson wrote:
From: Chris Withers <chrisw@nipltd.com>
But what's so bad about type()?!
When applied to an Extension Class, it gives you access to the actual class, rather than a nice inert type.
Hmmm.... arguably a bug in ExtensionClass, but not one I'm gonna try and fix ;-) Oh well, s'pose it's a good enough reason :-) cheers, Chris
At 05:25 PM 2/19/01 +0000, Chris Withers wrote:
Hmmm.... arguably a bug in ExtensionClass, but not one I'm gonna try and
fix ;-)
It's not a bug, it's a feature -- the feature that is the reason for the very existence of ExtensionClasses in the first place: merging of the notion of type and class. Of course, type() could always be replaced with a safe_type function that checked whether the type() was an ExtensionClass and returned something inert.
participants (3)
-
Chris Withers -
Evan Simpson -
Phillip J. Eby