[Patches] [ python-Patches-635933 ] make some type attrs writable
noreply@sourceforge.net
noreply@sourceforge.net
Thu, 05 Dec 2002 08:25:08 -0800
Patches item #635933, was opened at 2002-11-09 14:59
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=635933&group_id=5470
Category: Core (C code)
Group: Python 2.3
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Michael Hudson (mwh)
Summary: make some type attrs writable
Initial Comment:
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!
----------------------------------------------------------------------
>Comment By: Michael Hudson (mwh)
Date: 2002-12-05 16:25
Message:
Logged In: YES
user_id=6656
Don't know why this was still open.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2002-11-26 14:50
Message:
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 <TEXTAREA>...)
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-25 21:52
Message:
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?
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2002-11-22 16:34
Message:
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?
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2002-11-22 13:43
Message:
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.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-20 22:10
Message:
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!
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2002-11-20 16:09
Message:
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.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-15 16:50
Message:
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.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2002-11-15 10:01
Message:
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 <wink>, 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.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-14 17:28
Message:
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,
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2002-11-09 15:01
Message:
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...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=635933&group_id=5470