Guido van Rossum <guido@python.org> writes:
> > I guess one way of doing this would be to reimplement mro resolution
> > and so on in Python, which would be annoying and inefficient. Hmm.
>
> Alas, yes. You'd have to be able to write a class's tp_mro slot
> (corresponding to the __mro__ attribute), but there's no way to do
> that in Python, because it is too easy to cause mistakes. E.g. all
> C code that currently uses tp_mro assumes that it is a tuple whose
> items are either types or classic classes.
>
> The best thing to do would perhaps to make __mro__ assignable, but
> with a check that ensures the above constraint. I think I'd take a
> patch for that.
Shouldn't be too hard.
> I'd also take a patch for assignable __bases__. Note that there are
> constraints between __bases__ and __base__.
Should assigning to __bases__ automatically tweak __mro__ and
__base__? Guess so. What would assigning to __base__ do in isolation?
Perhaps that shouldn't be writeable.
> I'd also take a patch for assignable __name__.
This is practically a one-liner, isn't it? Not hard, anyway.
And there was me wondering what I was going to do this evening.
Cheers,
M.
--
Now this is what I don't get. Nobody said absolutely anything
bad about anything. Yet it is always possible to just pull
random flames out of ones ass.
-- http://www.advogato.org/person/vicious/diary.html?start=60
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