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!

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...

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,

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.

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.

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.

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!

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.

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?

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?

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>...)

Logged In: YES 
user_id=6656

Don't know why this was still open.