[Patches] [ python-Patches-635933 ] make some type attrs writable

noreply@sourceforge.net noreply@sourceforge.net
Wed, 20 Nov 2002 14:10:11 -0800


Patches item #635933, was opened at 2002-11-09 09: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: Open
Resolution: None
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: Guido van Rossum (gvanrossum)
Date: 2002-11-20 17: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 11: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 11: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 05: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 12: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 10: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