While it's rarely useful, there *are* situations where
assigning to __name__ or __bases__ of a class might
make sense.  So maybe this should be allowed.

Logged In: YES 
user_id=292741

e.g.
def mkclass(cname,something):
    class lcl:
        def __init__(self):
       ... yada...
        def f(self, parm = something):
         ... yada ...

   ... yada...
    lcl.__name__ = cname
    return lcl


My understanding is that this function returns a different
class object (each cut from the same cloth, as it were)
each time it is called, but they all have the same name
by default.
If you are doing this (which is a cool thing to be able to do)
it certainly makes sense to give each class a different
name.  I just tried this,  however, and it seems to work.
__name__ got changed, and instances have the new name
in their default repr(). 

Logged In: YES 
user_id=6380

I should've mentioned that this is only a problem for
new-style classes. To see the difference, try "class
lcl(object):" instead of "class lcl:" in your example.

But perhaps you should consider using a metaclass if you
really want the class objects to have different names.

Logged In: YES 
user_id=80475

Closing bug 591135 and merging it into this one.  Posting 
from Joost Jacob:

"""
In article: 
http://www.linuxjournal.com/article.php?sid=4540 
Chuck Esterbrook mentions an elegant technique 
called 'Mixin'. 

Assigning to __bases__ is useful if you want to add 
ancestors without changing the object's source code. 

It does not work with new-style classes because the 
.__bases__ attribute is now read-only. 
This is also mentioned on 
http://www.python.org/2.2.1/bugs.html 
at the bottom but I could not find a bug-report here at 
SF. 
"""

Logged In: YES 
user_id=33168

Michael, can this be closed now that your patch has been
checked in?

Logged In: YES 
user_id=6656

Yup, I think we can call this one dead.  My patch was
#635933, for reference.