Why PEP 245??

[Alex Martelli]

"Matt Butler" <foo at ix.netcom.com> wrote in message
news:9f298b$98n$1 at slb6.atl.mindspring.net...
    ...
>     Sometimes I code in Java, I can definitely say that the use of
> interfaces in Java has saved me time.  There have been several occasions
> where I was able to see that a class implemented a well-understood
interface
> and then not had to refer to the documentation anymore... I knew how it

I use COM a lot, and I can vouch for a similar effect *when interface
design doesn't badly violate the ISP* (when it does, interfaces become
useless -- http://www.objectmentor.com/publications/isp.pdf explains
it pretty well, IMHO).

Otoh, reading in Python docs "a list", "a sequence", "a file-like object",
"a function", and the like, never works as solidly -- that's because docs
are docs, not executable, not rigorous, not enforced.  Most of the places
that claim they want a function argument will work with any callable,
but not all; most that claim they want a dictionary want a real dictionary,
but some will make do with a user-defined mapping; and "file-like" is
a mistery -- the interface of 'file-like objects' is wide enough to break
the ISP, so it takes investigation in each case to determine exactly what
methods et al the function claiming it wants a file-like object does in
fact use (is .read() without argument enough, does it want .read(N)
instead, or perhaps .readline(), or .readlines(), or .xreadlines(), or...
oh, and, what about letting softspace be set and cleared, and tell,
seek, close, isatty, fileno, closed ... and we haven't started exploring
the _write_ side of things either!-).

Such fluidity is sometimes useful, but it does require exploratory
programming to deal with -- pseudo 'file objects' that mostly
report on what methods are being called/attributes accessed/&c
while trying to behave harmlessly, for example.  And you never
know whether in a next release the function that used to work
fine with your 'file-like object' that supports .read() but not
.read(N) will break -- you only (at best) discover what the current
version of the implementation is actually calling on the "file
like object", not what the contract is between the function and
the object you pass to it.  A formal, language-specified and
'executable' notion of interface would help (as long as ISP is
somehow *enforced*, I guess -- raising NotImplementedError
[like, in COM, returning E_NOTIMPL] implies the interface is
not well-segregated... such "partial conformance" removes much
of the usefulness, IMHO).


Alex