[Python-Dev] PEP 246, redux

[Alex Martelli]

On 2005 Jan 12, at 21:42, Phillip J. Eby wrote:
    ...
> Anyway, hopefully this post and the other one will be convincing that 
> considering ambiguity to be an error *reinforces* the idea of I-to-I 
> perfection, rather than undermining it.  (After all, if you've written 
> a perfect one, and there's already one there, then either one of you 
> is mistaken, or you are wasting your time writing one!)

I'd just like to point out, as apparently conceded in your "fair 
enough" sentence in another mail, that all of this talk of "wasting 
your time writing" is completely unfounded.  Since that "fair enough" 
of yours was deeply buried somewhere inside this huge conversation, 
some readers might miss the fact that your numerous repetitions of the 
similar concept in different words are just invalid, because, to recap:

Given four interfaces A, B, C, D, there may be need of each of the 
single steps A->B, A->C, B->D, C->D.  Writing each of these four 
adapters can IN NO WAY be considered "wasting your time writing one", 
because there is no way a set of just three out of the four can be used 
to produce the fourth one.

The only "redundancy" comes strictly because of transitivity being 
imposed automatically: at the moment the fourth one of these four 
needed adapters gets registered, there appear to be two same-length 
minimal paths A->x->D (x in {B, C}).  But inferring _from this 
consequence of transitivity_ that there's ANYTHING wrong with any of 
the four needed adapters is a big unwarranted logical jump -- IF one 
really trusted all interface->interface adapters to be perfect, as is 
needed to justify transitivity and as you here claims gets "reinforced" 
(?!).

Thinking of it as "redundancy" is further shown to be fallacious 
because the only solution, if each of those 4 adapters is necessary, is 
to write and register a FIFTH one, A->D directly, even if one has no 
interest whatsoever in A->D adaptation, just to shut up the error or 
warning (as you say, there may be some vague analogy to static typing 
here, albeit in a marginal corner of the stage rather than smack in the 
spotlight;-).

Yes, there is (lato sensu) "non-determinism" involved, just like in, 
say:
     for k in d:
         print k
for a Python dictionary d - depending on how d was constructed and 
modified during its lifetime (which may in turn depend on what order 
modules were imported, etc), this produces different outputs.  Such 
non-determinism may occasionally give some problems to unwary 
programmers (who could e.g. expect d1==d2 <--> repr(d1)==repr(d2) when 
keys and values have unique repr's: the right-pointing half of this 
implication doesn't hold, so using repr(d) to stand in for d when you 
need, e.g., a set of dictionaries, is not quite sufficient); such 
problems at the margin appear to be generally considered acceptable, 
though.

I seems to me that you do at least feel some unease at the whole 
arrangement, given that you say "this whole debate has made me even 
less enamored of adaptation", as it's not clear to me that any _other_ 
aspect of "this whole debate" was quite as problematic (e.g. issues 
such as "how to best get a special method from class rather than 
instance" -- while needing to be resolved for adaptation just as much 
as for copy.py etc -- hardly seem likely to have been the ones 
prompting you to go looking for "a cleaner, more intuitive way to do 
it" outside of the canonical, widespread approach to OOP).


Anyway -- I'm pointing out that what to put in a rewrite of PEP 246 as 
a result of all this is anything but obvious at this point, at least to 
me.


Alex