Python recipes: list mixin, improved timeit, etc

[barnesc]

I added some recipes to the Python Cookbook:

- listmixin

Use ListMixin to create custom list classes from a small subset of
list methods:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440656

- pytime

Improves on timeit by allowing you to time a function directly
(no need for confusing import and exec B.S.), and not requiring
you to specify the number of iterations for the timing loop.

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440657

- bitlist

An example of listmixin: A memory compacted list of bits, uses
1 byte per every 8 elements.

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440658


I hope you find these useful.

You can find more Python stuff by myself (and other misc thoughts) at
my blog (http://barnesc.blogspot.com/).

- Connelly Barnes

 

[Michele Simionato]

Well, suppose you have a class MyObject and you want to add to it some
methods to make its instances into a database. You could put these
methods into another class called Storable (the mixin class).
Then you can mix MyObject with Storable and get what you want,
a class StorableObject inheriting both from Storable and MyObject.
Of course you can reuse Storable to make storable even other
classes, for instance you could define a StorableOtherObject
inheriting from OtherObject and Storable.

Once in a time, I thought mixins where a good idea; now I don't think
so since they are too easily abused (see Zope 2) and as a consequence
you get spaghetti-inheritance, where you have objects with methods
inherited from everywhere. So be very careful if you want to use
mixins; often you can go without them.

Just my 2 Euro cents,

Michele Simionato

 

[Paul Rubin]

That looks great. Now, if only I understood mixins: what are they, and
what they are for, and in particular, how they differ from mere
subclassing.

I'm not sure what you mean by "mere subclassing" so maybe there is no
difference. Mixins are sort of a design pattern, not any whiz-tech
thing. The terminology comes from Flavors which was one of the early
multiple inheritance OOP systems. Flavors terminology was inspired by
ice cream: you could go to Tosci's and get plain ice cream, or ice
cream with your choice of various mix-ins like raisins, M&M's, heath
bar pieces, etc., which you could combine orthogonally. In Flavors
and in Python, mix-ins are superclasses that you inherit to turn on a
feature. The classic example is a Window class, with mixins for
scroll bars, title bars, pulldown menu, etc. So if you want a window
with a scroll bar, you'd say

class Window_with_scroll_bar(Window, Scrollbar): pass

and you'd get a class that understands the operations of both windows
and scroll bars. Flavors had automatic method combination that you
have to spell out manually in Python, making the scheme a little bit
less useful. But see SocketServer for a clever example of mixins to
implement concurrency in a TCP listener. The basic server class is
TCPServer and you inherit from ThreadingMixin to make a threading
server or ForkingMixin to make a forking server.

I guess what makes something a mix-in is that you normally don't
inherit from it directly. You inherit from some other class and the
mix-in is an "add-on" superclass that supplies some extra functionality.

 

[Steven D'Aprano]

I added some recipes to the Python Cookbook:

- listmixin

Use ListMixin to create custom list classes from a small subset of
list methods:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440656

That looks great. Now, if only I understood mixins: what are they, and
what they are for, and in particular, how they differ from mere
subclassing.

I've spent some time searching for a good definition on the web, but the
main problem I've found is that most discussions on mixins assume
you already know what they are. Those that don't are talking about
Ruby or Lisp or some other language other than Python. I don't speak
those languages, so their code examples don't make a lot of sense to me.

Anyhoo, I've struggled on, but obviously I Just Don't Get It because
using mixins looks like subclassing to me.

Can anyone help me understand what's going on?


Thanks,

 

[Paul Rubin]

Once in a time, I thought mixins where a good idea; now I don't think
so since they are too easily abused (see Zope 2) and as a consequence
you get spaghetti-inheritance, where you have objects with methods
inherited from everywhere. So be very careful if you want to use
mixins; often you can go without them.

Yeah, I wonder though how much of that is a result of Python's
cavalier approach to multiple inheritance. Does that happen much in
CLOS? In Java because of multiple interfaces? I've studied Flavors a
little and mix-ins were used in some extensive ways, but maybe
programs using them required extra care.

The Python tutorial does caution against indiscriminate use of
multiple inheritance. I tried coding something without it, wished
that I'd used it and did so in the next version, but still am not sure
if I gained anything or not.

 

[Mike Meyer]

That looks great. Now, if only I understood mixins: what are they, and
what they are for, and in particular, how they differ from mere
subclassing.

One way to look at it is that mixins are a special case of
subclassing. They aren't different, just specific.

Mixins are abstract. Using Paul's example, you'd never declare a
ScrollBar object, only subclasses that also inherit from some form of
Window.

Mixins are about behavior, not type. If you have real mixins, then an
object of a class that inherits from a mixin is not an instance of the
mixin class.

Mixins are one way to deal with the lack of multiple inheritance. But
even languages with multiple inheritance find the idea useful.

<mike

 

[Michele Simionato]

Yeah, I wonder though how much of that is a result of Python's
cavalier approach to multiple inheritance. Does that happen much in
CLOS? In Java because of multiple interfaces? I've studied Flavors a
little and mix-ins were used in some extensive ways, but maybe
programs using them required extra care.

I don't think Python approach to multiple inheritance is cavalier (you
may want
to clarify that statement). In CLOS multiple inheritance is less of a
problem
since (multi)methods are defined outside classes. One could argue that
using classes also as a scope-control mechanism (i.e. doing the job of
modules) is an abuse.

The Python tutorial does caution against indiscriminate use of
multiple inheritance. I tried coding something without it, wished
that I'd used it and did so in the next version, but still am not sure
if I gained anything or not.

Nowadays I tend to use delegation via __getattr__ instead of multiple
inheritance.

Michele Simionato

 

[Steven D'Aprano]

Well, suppose you have a class MyObject and you want to add to it some
methods to make its instances into a database. You could put these
methods into another class called Storable (the mixin class).
Then you can mix MyObject with Storable and get what you want,
a class StorableObject inheriting both from Storable and MyObject.
Of course you can reuse Storable to make storable even other
classes, for instance you could define a StorableOtherObject
inheriting from OtherObject and Storable.

So mixins are just a sub-class [pun intended] of sub-classing?

I've just found this:

A mixin class is a parent class that is inherited from - but not as
a means of specialization. Typically, the mixin will export services to a
child class, but no semantics will be implied about the child "being a
kind of" the parent.
[end quote]

from http://c2.com/cgi/wiki?MixIn

Is that all they are?

It is amazing how you can take the simplest concept, and by using
appropriate terminology, make it as confusing and opaque as you want...

*wink*

 

[George Sakkis]

I've just found this:

A mixin class is a parent class that is inherited from - but not as
a means of specialization. Typically, the mixin will export services to a
child class, but no semantics will be implied about the child "being a
kind of" the parent.
[end quote]

from http://c2.com/cgi/wiki?MixIn

Is that all they are?

It is amazing how you can take the simplest concept, and by using
appropriate terminology, make it as confusing and opaque as you want...

*wink*

Now this reminds me of Xah's entertaining posts about "moronicities of the tech-geek industry
jargon" <wink>.

George