[Python-Dev] PEP 246: lossless and stateless

[Armin Rigo]

Hi Guido,

On Thu, Jan 13, 2005 at 10:20:40PM -0800, Guido van Rossum wrote:
> Hm. Maybe that post points out that adapters that add state are bad,
> period. I have to say that the example of adapting a string to a file
> using StringIO() is questionable. Another possible adaptation from a
> string to a file would be open()

I have some theory about why adapting a string to a file in any way is
questionable, but why adapting some more specific class to some other class
usually "feels right", and about what "lossy" means.  In my opinion a
user-defined class or interface mixes two notions: a "concept" meaningful for
the programmer that the instances represent, and the "interface" provided to
manipulate it.  Adaptation works well at the "concept" level without all the
hassles of information loss and surprizes of transitive adaptation.  The
problems show up in the cases where a single concrete interface doesn't
obviously match to a single "concept".  For example, strings "mean" very
different concepts in various contexts, e.g. a file name, an url, the byte
content a document, or the pickled representation of something.  Containers
have the similar problem.  This suggests that only concrete objects which are
expected to encode a *single* concept should be used for adaptation.

Note that the theory -- for which I have an old draft at
http://arigo.tunes.org/semantic_models.html -- suggests that it is possible to
be more precise about various levels of concepts encoding each others, like a
string standing for the name of a file itself encoding an image; but I'm not
proposing anything similar here, just suggesting a way to realize what kind of
adaptation is problematic.

> may be specific cases where the conventions of a particular
> application or domain make stateful or otherwise naughty adapters
> useful, and everybody understands the consequences and limitations.

Note that it may be useful to be able to register some adapaters in "local"  
registeries instead of the single global one, to avoid all kinds of unexpected
global effects.  For example something along the lines of (but nicer than) :

  my_registry = AdapterRegister()
  my_registry.register(...)
  my_registry.adapt(x, y)   # direct use

  __adaptregistry__ = my_registry
  def f(x as y):   # implicit use of the module-local registry
      stuff

This would allow a module to provide the str->StringIO or str->file conversion
locally.


A bientot,

Armin.