[Python-Dev] metaclass insanity (original) (raw)

Michael Hudson mwh@python.net
04 Nov 2002 17:10:46 +0000

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 typesetclass, 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 tpname? Is there any way for a user > defined class to end up called "something.somthingelse"?

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 "", line 1, in ? > AttributeError: module > > caused by lax testing in typesetmodule.

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