OddThinking

Ignoring your warnings, I put a few minutes thought into this. Would this be the dynamic-language equivalent of generics in Java or templates in C++?

Hypothetical example: a codec class that overrides the read and write methods to convert text strings to/from the correct encoding type. Given a class that support read and write, you could pass it in as a base class to the codec class. This would allow encoding and decoding of text from files, networks, pipes, etc etc.

Not saying this is an ideal design for the problem of text encoding, but maybe it’s enough to avoid developer livelock about the general concept?

Well, Alastair,

You have broken the livelock but every time I think about it, I still feel a little dirty.

The Zen of Python tells us “There should be one– and preferably only one –obvious way to do it.” So my tactic has been to think about what that one obvious way to do this would be. The longer I think about it, the more “obvious” it will have to be when I discover it.

The problem we are solving is to create a class that can encapsulate an arbitrary file-like class, called flc, behind a proxy class that adds text coding and encoding.

Obvious solution candidate # 1:

Inherit from flc and add the codec handling (perhaps by encapsulating a codec object.)

Problem: Requires significant custom code for each flc class we come across.

Obvious solution candidate # 2:

Multiple base classes: codec class then flc class.

Problem: Can the codec class’s read method successfully refer to, and call, the flc class’s read method? I suspect not, but am not sure. It it is possible, it certainly isn’t obvious.

Obvious solution candidate # 3:

Common or garden encapsulation – pass the flc instance to the codec class’s constructor.

Problem: Only permits (transparent) access to the pre-agreed methods. Any other methods on flc will be hidden.

The good news is that Python 3000 has some clearer definitions of what methods are required to be considered “file-like”, but this might still be a problem if your particular class offers an obscure operation.

Obvious solution candidate # 4:

Encapsulation, but add fake proxy methods into the class’s dictionary during the instance’s construction, based on introspection on the encapsulation class.

Problem: Ugh, now see what you’ve made me do! I have to stop now, before I go too far.

I need a shower!

Interestingly, the Python codec module uses obvious solution #3, and the problem you mentioned is solved by decree:

In addition to the above methods, the StreamReader must also inherit all other methods and attributes from the underlying stream.

Not sure how it does this! Maybe some magic with dir() ?

Anyway, just out of interest, how does your OO Brain cope with function/method/class decorators? These are current Python features which I find mildly confusing…