[Python-Dev] PEP 246, redux

[Alex Martelli]

On 2005 Jan 13, at 19:21, Clark C. Evans wrote:
    ...
> Are you _sure_ you have M*N adapters here?  But even so,

Yep.

>   for j in (J1,J2,J3,J4,...,JM)
>     for i in (I1,I2,...,IN):
>       register(j,i)

Uh?  WHAT are you registering for each j->i...?

> The other issue with registries (and why I avoided them in the 
> origional
> PEP) is that they often require a scoping; in this case, the path taken
> by one module might be different from the one needed by another.

I think that should not be supported, just like different modules 
cannot register different ways to copy.copy(X) for the same X.  One 
size had better fit all, be it a single specific adapter or potentially 
a path thereof.

> | The convenience of this is undeniable; and (all other things being
> | equal) convenience raises productivity and thus is valuable.
>
> It also hides assumptions.  If you are doing adaptation paths


Not sure if it hides them very deeply, but yes, there may be some 
aspects of "information hiding" -- which is not necessarily a bad 
thing.

> Ok.  I just think you all are solving a problem that doesn't exist,

Apparently, the existence of the problem is testified by the experience 
of the Eclipse developers (who are, specifically, adapting plugins: 
Eclipse being among the chief examples f plugin-based architecture... 
definitely an N-players scenario).


> and in the process hurting a the more common use case:
>
>    A component developer X and a framework developer Y both
>    have stuff that an application developer A is putting
>    together.  The goal is for A to not worry about _how_ the
>    components and the framework fit; to automatically "find"
>    the glue code.
>
> The assertion that you can layer glue... is well, tenuous at best.

If you ever did any glueing (of the traditional kind, e.g. in 
historical-furniture restoration, as opposed to relatively new miracle 
glues) you know you typically DO layer glue -- one layer upon one of 
the pieces of wood you're glueing; one layer on the other; let those 
two dry a bit; then, you glue the two together with a third layer in 
the middle.  Of course it takes skill (which is why although I know the 
theory when I have any old valuable piece of furniture needing such 
restoration I have recourse to professionals;-) to avoid the 
easy-to-make mistake of getting the glue too thick (or uneven, etc).

I'm quite ready to consider the risk of having too-thick combined 
layers of glue resulting from adaptation (particularly but not 
exclusively with transitivity): indeed PJE's new ideas may be seen as a 
novel way to restart-from-scratch and minimize glue thickness in the 
overall resulting concoction.  But the optional ability for 
particularly skilled glue-layers to have that extra layer which makes 
everything better should perhaps not be discounted.  Although, 
considering PJE's new just-started effort, it may well be wisest for 
PEP 246 to stick to a minimalist attitude -- leave open the possibility 
of future additions or alterations but only specify that minimal core 
of functionality which we all _know_ is needed.


> | In terms of "should" as opposed to convenience, though, the argument 
> is
> | that interface to interface adapters SHOULD always, inherently be
> | suitable for transitive chains because there is NO reason, EVER, 
> under
> | ANY circumstances, to have such adapters be less than perfect,
> | lossless, noiseless, etc, etc.
>
> I strongly disagree; the most useful adapters are the ones that
> discard unneeded information.

The Facade design pattern?  It's useful, but I disagree that it's "most 
useful" when compared to general Adapter.  My favourite example is 
wrapping a str into a StringIO to make a filelike readable object -- 
that doesn't discard anything, it *adds* a "current reading point" 
state variable (which makes me dubious of the new "no per-state 
adapter" craze, which WOULD be just fine if it was true that discarding 
unneeded info -- facading -- is really the main use case).

>   The big picture above, where you're
> plugging components into the framework will in most cases be lossy
> -- or the frameworks / components would be identical and you woudn't
> want to hook them up. Frankly, I think the whole idea of "perfect
> adapters" is just, well, arrogant.

So please explain what's imperfect in wrapping a str into a StringIO?


> | What about "registered explicitly as being suitable for 
> transitivity",
> | would that suffice?
>
> I suppose so.  But I think it is a bad idea for a few reasons:
>
>   1. it seems to add complexity without a real-world justifcation,
>      let's go without it; and add it in a later version if it turns
>      out to be as valueable as people think

Particularly in the light of PJE's newest ideas, being spare and 
minimal in PEP 246 does sound good, as long as we're not shutting and 
bolting doors against future improvements.


>   2. different adapters have different intents, and I think a given
>      adapter may be perfect in one situation, it may royally
>      screw up in another; users of systems often break interfaces
>      to meet immediate needs.  In your strawman I can think of
>      several such twists-and-turns that an "obviously perfect"
>      adapter would fail to handle:
>
>        - In the 'structure' variety (where the middle name is
>          not necessarly placed in the middle), someone decides
>          to store one's title... beacuse, well, the slot is
>          there and they need to store this information
>
>        - In the 'ordered' variety, "John P. Smith", you might
>          have "Murata Makoto".  If you thought Makoto was the
>          last name... you'd be wrong.

If you've ever looked into "quality of data" issues in huge databases, 
you know that these are two (out of thousands) typical problems -- but 
not problems in _adaptation_, in fact.

> In short, unless a human is giving the 'ok' to an adapter's
> use, be it the application, framework, or component developer,
> then I'd expect wacko bugs.

A lot of the data quality problems in huge databases come exactly from 
humans -- data entry issues, form design issues, ... all the way to 
schema-design issues.  I don't see why, discussing a data-quality 
problem, you'd think that having a human OK whatsoever would help wrt 
having a formalized rule (e.g. a database constraint) do it.


> | This potentially opens the door to N-players scenarios for N>3, but,
> | like going from 3-tier to N-tier applications, that's not as huge a
> | jump as that from N==2 to N==3;-).
>
> The problem with registries is that often times scope is needed;
> just beacuse my module wants to use this adaption path, doesn't
> mean your module will make the same choice.  I avoided registries
> in the first pass of the draft to avoid this issue.  So, if we
> are going to add registries, then namespaces for the registries
> need to also be discussed.

If _one_ registry of how to copy/serialize things is good enough for 
copy.py / copy_reg.py / pickle.py / ..., in the light of minimalism we 
should specify only one for PEP 246 too.


> | So, are you willing to do that round of editing to PEP 246...?  I'll
> | then to the NEXT one which will still undoubtedly be needed...
>
> I could make a wack at it this weekend.

Great!  I assume you have copies of all relevant mails since they all 
went around this mailing list, but if you need anything just holler, 
including asking me privately about anything that might be unclear or 
ambiguous or whatever -- I'll be around all weekend except Sunday night 
(italian time -- afternoon US time;-).


Thanks,

Alex