Greg Ewing <greg@cosc.canterbury.ac.nz> writes:
> Guido:
Er, this was me.
>> one approach would be special cases in PyObject_GenericSetAttr,
>> I guess.
>
> Before using a hack like that, it might be better to think about what
> the real problem is.
Aww :-)
> Seems to me the problem in general is that there's no way to prevent a
> class which overrides a method from having a superclass version of
> that method called through a back door. Which means you can't rely on
> method overriding to *restrict* what can be done to an object.
>
> So a proper fix would require either:
>
> (1) Providing some way for objects to prevent superclass
> methods from being called on them when they're not looking
>
> or
>
> (2) Fixing the typeobject not to rely on that for its security --
> by hiding the real dict more deeply somehow?
Yeah, another option would be to make _PyObject_GetDictPtr respect
__dict__ descriptors. But that's probably the Wrong Answer, too.
Maybe just PyObject_GenericSetAttr should do that -- call
PyObject_GetAttr(ob, '__dict__'), basically.
bad-answers-on-demand-ly y'rs
M.
--
We did requirements and task analysis, iterative design, and user
testing. You'd almost think programming languages were an interface
between people and computers. -- Steven Pemberton
(one of the designers of Python's direct ancestor ABC)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4