| msg41593 - (view) |
Author: Michael Hudson (mwh)  |
Date: 2002-11-09 14:59 |
| As per discussion on python-dev, this patch makes the following attributes of type objects writable from Python: - __name__ - __bases__ - __mro__ It also relaxes the restriction on not returning __module__ when that's been set to a non-string. This (tiny) part is a 2.2.3 candidate IMHO. It lets the following work: class C(object): pass class D(C): pass class E(object): def meth(self): print 1 d = D() D.__bases__ = (C, E) d.meth() but that's the extent of my testing so far. Needs a test and docs -- if the current behaviour is documented anywhere. Currently, if an assignment to __bases__ would change __base__, it complains (was easiest). Assigned to Guido so he sees it, but anyone else is encouraged to review it! |
|
|
| msg41594 - (view) |
Author: Michael Hudson (mwh) |
Date: 2002-11-09 15:01 |
| Logged In: YES user_id=6656 Hmm, I misunderstood __base__. It's the base class that *leads* to the solid base, not the solid base. So an assignment to __bases__ may justifyable change it. Oops. Will try again later... |
|
|
| msg41595 - (view) |
Author: Guido van Rossum (gvanrossum) * |
Date: 2002-11-14 17:28 |
| Logged In: YES user_id=6380 Michael, can you checking some of this in as separate pieces? The __module__ relaxation should go in first, and marked as backport candidate. The __name__ fix is close, but I think it *should* be allowed to put dots in the name (this is actually a feature for old classes); instead of '.' I want a check that there are no \0 bytes in the string (see set_name() in classobject.c). I think the restrictions on __bases__ are sufficiently thought out; with old-style classes, you can do much more class switching: >>> class C: pass >>> class D: pass >>> D.__bases__ = (C,) >>> I'd like this to work for new-style classes too. It means that __base__ has to change though. There's a bug in set_mro(): it checks PyInstance_Check() where it clearly means PyClass_Check(). Other than that I think it's good to go. (Though this is the ultimate weird feature! What's the use case again?) Hoping for unit tests, |
|
|
| msg41596 - (view) |
Author: Michael Hudson (mwh) |
Date: 2002-11-15 10:01 |
| Logged In: YES user_id=6656 All the code for this is on my laptop, which is at home, so nothing is getting checked in until Monday at the earliest. > Michael, can you checking some of this in as separate pieces? Rearranging that so it makes sense , yes that's probably a good idea. > The __module__ relaxation should go in first, and marked as > backport candidate. OK. Easy. > The __name__ fix is close, but I think it *should* be > allowed to put dots in the name (this is actually a feature > for old classes); instead of '.' I want a check that there > are no \0 bytes in the string (see set_name() in classobject.c). OK. > I think the restrictions on __bases__ are sufficiently > thought out; Do you mean INsufficiently thought out? If so, I agree. It also occurred to me that there's probably stuff to be done so __subclasses__() continues to work. > There's a bug in set_mro(): it checks PyInstance_Check() > where it clearly means PyClass_Check(). Doh. > Other than that I think it's good to go. > (Though this is the ultimate weird feature! What's the use > case again?) Well, with assignment to __bases__ I don't need it anymore. > Hoping for unit tests, There's NO WAY I'm checking this in without them, don't worry. When do you want this done by? It might take a week or two. |
|
|
| msg41597 - (view) |
Author: Guido van Rossum (gvanrossum) * |
Date: 2002-11-15 16:50 |
| Logged In: YES user_id=6380 Monday is fine! Sorry for the typos. If you don't need __mro__ assignment, let's not do that part then. I'd like to see it done ASAP, but at least before we release Python 2.3a1 -- which is due before Xmas. |
|
|
| msg41598 - (view) |
Author: Michael Hudson (mwh) |
Date: 2002-11-20 16:09 |
| Logged In: YES user_id=6656 Here's an update, just in case my hard drive explodes or something. I'm still not sure what should and shouldn't be allowed for __name__, but I haven't thought about it too hard. If you have time, an email with one-syllable-per-word instructions would be appreciated :) __bases__ is getting there: __subclasses__ still works. This doesn't, though: pass class C2(object): def __getattribute__(self, attr): if attr == 'a': return 1 else: return super(C2, self).__getattribute__(attr) def meth(self): print 1 class D(C): pass d = D() D.__bases__ = (C2,) d.a sigh, more complexity. Should have some hours to spend on this this week. I've started on the test suite, but that's not part of the diff yet. |
|
|
| msg41599 - (view) |
Author: Guido van Rossum (gvanrossum) * |
Date: 2002-11-20 22:10 |
| Logged In: YES user_id=6380 The new patch still requires that the new __name__ value not contain a '.'. Instead, it should allow any string that doesn't contain a null byte. No time to comment on the rest; good luck! |
|
|
| msg41600 - (view) |
Author: Michael Hudson (mwh) |
Date: 2002-11-22 13:43 |
| Logged In: YES user_id=6656 Not really relavent, but I've got to say it somewhere... I've just had one of those "aha!" moments: in D.__base__ = (C2,) you need to not only muck with D's __mro__ but also the __mro__'s of D's sublcasses! Argh! mwh, off to find a wall to bang his head against. |
|
|
| msg41601 - (view) |
Author: Michael Hudson (mwh) |
Date: 2002-11-22 16:34 |
| Logged In: YES user_id=6656 OK, I think this is really nearly ready. There are some weird interactions betwixt __name__ and __module__ when you start slinging strings with dots in around. Can we assume heap types always have a "__module__" key in their dicts? I think the __bases__ code is good to go. A review is probably a good idea, of course. Are there docs that need updating? |
|
|
| msg41602 - (view) |
Author: Guido van Rossum (gvanrossum) * |
Date: 2002-11-25 21:52 |
| Logged In: YES user_id=6380 Michael, unfortunately I have no time for a thorough review. Maybe you should just check it in so others can review it. I'm somewhat uncomfortable with assuming there's always a __module__ attribute in a heaptype, even though I believe that is indeed the case. Why do you need this assumption? |
|
|
| msg41603 - (view) |
Author: Michael Hudson (mwh) |
Date: 2002-11-26 14:50 |
| Logged In: YES user_id=6656 OK, I've checked in Objects/typeobject.c revision 2.189 Lib/test/test_descr.py revision 1.163 Misc/NEWS revision 1.545 Doc/whatsnew23.tex revision 1.75 I'll raise the concerns I have about __name__ on python-dev (beats typing into a |
|
|
| msg41604 - (view) |
Author: Michael Hudson (mwh) |
Date: 2002-12-05 16:25 |
| Logged In: YES user_id=6656 Don't know why this was still open. |
|
|