Typing system vs. Java

[Alex Martelli]

"Jonathan Hogg" <jonathan at onegoodidea.com> wrote in message
news:jonathan-08E8BC.11505504082001 at news.easynet.co.uk...
    ...
> Since I can write more powerful programs in smaller, more readable
> chunks, I think I write less buggy code. If we have to reduce the
> simplicity/expressiveness of the language in order to add type-checking,
> then I think the tradeoff is not worth it.
>
> I'd argue that even the protocols/interfaces idea falls into this
> category. Since the majority of protocol/interface errors fall out in
> runtime testing very quickly, the additional effort that would be
> required to specify the interfaces and the hugely difficult compilation
> problem of enforcing them, just doesn't add up for me.

I agree with most of what you're saying but I think you have
the wrong viewpoint about the protocol-adaptation PEP.  It
most assuredly doesn't reduce the expressiveness of Python,
and the "simplicity reduction" is minimal and in an excellent
cause.  Consider...:

Say that function A receives as an argument object x.  Now, A
needs to use x according to the "sequential binary file-reading
protocol".  How do you handle that in Python today?  If you're
lucky, A's author will mention that x must be a file-like object.
More likely A's author will falsely say that x must be a file (you
need to read code and experiment to prove that A's author
was lying).  Hardly ever will A's author specify what _subset_
of a file's functionality x must supply -- is it .read (does x need
to support .read(N), or just .read()?), .readline, .readlines,
.xreadlines, ...?  Does x.close() have to work?  What about
x.tell and x.seek -- do THOSE need to work?

And what happens if client code starts with the data in a
form that isn't a file?  Presumably client code imports
cStringIO and explicitly wraps (adapts) the string-form
data for A's consumption -- but often A's author supplies
two functions, A(fileobj) and As(stringobj) too.  And what
if x is neither a file nor a string but some other kind of
object yet -- who's responsible for knowing how x gets
adapted to the file protocol...?

Having a *standard* way to request adapt-to-protocol
does away with most of these issues; it _promotes_
simplicity for both the author of A and the author of
client code.  A's author asks for adaptation of argument
x to the protocol A needs; A's client passes any object
as x that can be adapted to the protocol; the adaptation
framework does the rest -- whether the 'adaptation' is
a no-operation (x itself already supports the protocol),
a standard wrapping (cStringIO to wrap a string object
into file protocol), or something specified by the author
of *x* (somebody else again from the authors of A and
of A's client code) by registering suitable hooks with the
adaptation framework, or by somebody else again.

That's not "type checking" as an overhead in development
for the purpose of getting some errors diagnosed a bit
earlier or getting some extra runtime performance: it's
something else altogether -- it's a provision of a standard
way for multiple authors of reusable components and
client-code of those components to resolve 'impedance
mismatches' (protocol differences) that inevitably arise.


Alex