operations on types

Dr. John Q. Hacker zondervanz at gmail.com
Tue Jun 16 22:42:47 EDT 2015


On Tue, Jun 16, 2015 at 9:04 PM, Steven D'Aprano <
steve+comp.lang.python at pearwood.info> wrote:

> On Tue, 16 Jun 2015 19:24:03 -0500, Dr. John Q. Hacker wrote:
>
> > [Dr. Bigcock wrote:]
> >> The current syntax for adding functionality to a class using mix-in
> >> style via inheritance list conflates two very different things.
>
> I'm not sure why you are taking "Dr Bigcock" seriously. You know he isn't
> actually a doctor?
>

Actually, I asked him.  He said he was has a PhD in Theology.

> > That's an awesome idea.  It's like a final way to understand and operate
> > > with metaclasses.
> >
> > Unfortunately, it has nothing to do with metaclasses.
>

 No, it *does*:  it's operations on classes themselves (i.e. types) and not
on *instantiations* of classes.  If that isn't metaclassing, then python's
been calling it wrong.

> I can see why:
> >
> >     NewType = OldType + Mixin
> >
> > appears more attractive at first glance than:
> >
> >     class NewType(OldType, Mixin):
> >         pass
> >
> > since it saves a lot of boilerplate. But in practice, the body of the
> > class is not often "pass". More often, you end up overriding or adding
> > new methods. In that case, the suggested syntax has no advantage.
>

Adding new methods is exactly what this syntax is supposed to do.

The tricky part is overriding existing methods.  If Python's dict (or
defaultdict) type, provided an optional collision parameter, this could be
user-defined.  Probably the __doc__ attribute could be concatenated (the
simple, naive solution) while the code would have to be merged in some
fashion.

zipher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20150616/3f4e1b7b/attachment.html>


More information about the Python-list mailing list