[Python-Dev] PEP 246, redux

[Clark C. Evans]

On Thu, Jan 13, 2005 at 08:40:56PM +0100, Alex Martelli wrote:
| >The other issue with registries (and why I avoided them in the 
| >origional) 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.

Sounds good.

| >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).

Some specific examples from Eclipse developers would help then,
especially ones that argue strongly for automagical transitive
adaptation.  That is, ones where an alternative approach that
is not automatic is clearly inferior.

| >   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.
... 
| 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.

I do like PJE's idea, since it seems to focus on declaring individual 
functions rather than on sets of functions; but I'm still unclear
what problem it is trying to solve.

| 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.

I'd rather not be pushing for a powerful regsistry mechansim unless
we have solid evidence that the value it provides outweighs the costs
that it incurres.

| >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 qualification was not very well placed.  That said, I don't see any 
reason why a facade can't also be asked for via the adapt() mechanism.

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

It adds information, and it implies mutability which the underlying
object is not.  In short, it's quite a different animal from a String,
which is why String->StringIO is a great example for an adapter.

| >| 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.

Agreed!

| >  2. different adapters have different intents...
|
| 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.

I deal with these issues all of the time; but what I'm trying to
express with the example is that someone may _think_ that they are
writing a perfect adapter; but they may be wrong, on a number of
levels.  It's not so much to say what is good, but rather to 
challenge the notion of a 'perfect adapter'. 

| >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.

The point I was trying to make is that automatically constructing
adapters isn't a great idea unless you have someone who can vouche
for the usefulness.  In other words, I picture this as a physics
story problem, where a bunch of numbers are given with units. While
the units may keep you "in check", just randomly combining figures
with the right units can give you the wrong answer.

| >| 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;-).

Ok.

Best,

Clark
-- 
Clark C. Evans                      Prometheus Research, LLC.
                                    http://www.prometheusresearch.com/
    o                               office: +1.203.777.2550 
  ~/ ,                              mobile: +1.203.444.0557 
 //
((   Prometheus Research: Transforming Data Into Knowledge
 \\  ,
   \/    - Research Exchange Database
   /\    - Survey & Assessment Technologies
   ` \   - Software Tools for Researchers
    ~ *