[Python-Dev] PEP 246, redux (original) (raw)

Alex Martelli aleax at aleax.it
Thu Jan 13 11:31:30 CET 2005

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

More information about the Python-Dev mailing list