[Python-Dev] metaclass insanity

[Michael Hudson]

Guido van Rossum <guido@python.org> writes:

> > > > Should assigning to __bases__ automatically tweak __mro__ and
> > > > __base__?  Guess so.
> > > 
> > > Yes.  Note that changing __base__ should not be done lightly --
> > > basically, the old and new base must be layout compatible, exactly
> > > like for assignment to __class__.
> > 
> > OK.  I can crib code from type_set_class, I guess.  Or one could just
> > allow assignment to __bases__ when __base__ doesn't change?  __base__
> > is object for the majority of new-style classes, isn't it?
> 
> But if you derive from a builtin type (e.g. list or dict), __base__
> will be that.

True.  But I was going for low hanging fruit.

> > Brr.  There's a lot I don't know about post 2.2 typeobject.c.
> 
> Me too. :-)

I'm not sure that remark warrants a smiley...

> > > > What would assigning to __base__ do in isolation?
> > > > Perhaps that shouldn't be writeable.
> > > 
> > > Perhaps it could be writable when __bases__ is a 1-tuple.
> > 
> > Don't see the point of that.
> > 
> > > But it's fine if it's not writable.
> > 
> > Easier :)
> 
> Agreed.

Good.

> > > > > I'd also take a patch for assignable __name__.
> > > > 
> > > > This is practically a one-liner, isn't it?  Not hard, anyway.
> > > 
> > > Probably.  Can't remember why I didn't do it earlier.
> > 
> > It's a bit more complicated than that.
> > 
> > What's the deal wrt. dots in tp_name?  Is there any way for a user
> > defined class to end up called "something.somthing_else"?
> 
> I hope not.  The dots are for extensions living inside a package;
> everything before the last dot ends up as __module__.

Fine.

What happens for nested classes?

In 

class X:
    class Y:
        pass

are X.Y instances picklable without extra fiddling?

> > Oh, and while we're at it, here's a bogosity:
> > 
> > >>> class C(object):
> > ...  pass
> > ... 
> > >>> C.__module__ 
> > '__main__'
> > >>> C.__module__ = 1
> > >>> C.__module__ 
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> > AttributeError: __module__
> > 
> > caused by lax testing in type_set_module.
> 
> Oops.  Can you fix it?  Or are there complications?

No, should be easy.

    if (!PyString_Check(arg)) {
           PyErr_SetString(PyExc_TypeError,
                           "don't do that");
           return -1;
    }

or something like that.

> Seems to be broken in 2.2 too.

Yes.  It's a change in behaviour, but I *really* can't see anyone
relying on that one.

> > > > And there was me wondering what I was going to do this evening.
> > > 
> > > I don't have that problem -- a Zope customer problem was waiting for
> > > me today. :-(
> > 
> > Well, I didn't get it finished either.  Fiddly, this stuff.  Maybe by
> > tomorrow.
> 
> Great!
> 
> I'll be offline Friday through Monday -- going to a weekend conference.

Not that it mattered -- I still haven't finished.  Damn EV Nova and
its plugins...

Cheers,
M.

-- 
  Indeed, when I design my killer language, the identifiers "foo" and
  "bar" will be reserved words, never used, and not even mentioned in
  the reference manual. Any program using one will simply dump core
  without comment. Multitudes will rejoice. -- Tim Peters, 29 Apr 1998