Python and generic programming

[Jeremy Bowers]

On Fri, 22 Oct 2004 09:25:49 +0400, Roman Suzi wrote:

> 
> 
> Sincerely yours, Roman A.Suzi

OK, independent of the usual top-posting debate, you *really* need to not
top-post a Usenet signiture (two dashes followed by a space). I hit reply
and this is all my (conformant) newsreader picked up as the message; the
rest is (correctly in the abstract) considered a signiture. 

Anyhow, I have a question:

> Most Python programs are already kinda generic, yes. But generic
> programming adds multi-sorted types control and constraints to ensure
> type safety...

Is this type safety that you refer to truly necessary according to
somebody's definition of "generic programming"? If so, can you link to it?
(Maybe not, as it may just be in a paper; I'm asking for info if it's
easy, not if it is hard.)

See, some people insist that the kind of type safety that you are
referring to are absolutely, positively necessary in OO, too. But then
these people are left unable to explain why Python programs fail to fly
apart at the seams as they get larger. (This was one of the things that
finally broke me of the strong typing inculcation I received in school;
strong typing, considered as a scientific theory (something like "Large
programs must be strongly typed, or they will cease working and
maintenance will become impossible"), made claims about programs that
proved to be wrong. Therefore, discard the theory. (Which isn't to say it
is *useless*, just that the cause/effect theories didn't pan out.))

So I am honestly asking (since I don't know), is it really *necessary*
according to some reasonably widely acknowledged definition of "generic
programming, or is it a continued holdover from 25+ years of strong typing
dogma that might also be disproved by an existing implementation that
falsifies the theoretical claims?

Generic programming to me has been the recognition that it can be powerful
to program to interfaces/concepts/capabilities. There is a core idea in
that three-word block, but the implementation differs from language to
language, and one should not confuse a given implementation, esp. in a
language predating the term, with the idea of "generic programming". As
with about half of the "Design Patterns", Python does "generic
programming" so easily that it can be easy for someone used to jumping
through hoops and being caught up in the trappings to not recognize that
Python captures the essence with little or no effort. 

In this case, it is "no" effort: Python does generic programming in this
sense *automatically*, every time you write an algorithm, and you have to
work hard to avoid it. (Though for any given algorithm it may of course
end up depending intimately on some set of properties such that it can't
conceivably be used generically, but *Python* isn't standing in the way.)
In fact, if Alex Martelli had a dime for every time he smacked someone
metaphorically on this newsgroup for so breaking the genericity of the
algorithm (by unnecessarily using "isinstance", usually), he'd, well, be
able to buy a very, very nice dinner.

So I guess I'd emphasize that I am quite explicitly *not* asking about the
trappings of a given implementation; I'm asking about the true essence of
the idea. My feeling is no, but I am not an expert on generic programming
and would look forward to learning how I might be wrong here, even with my
evident biases (/experience) on the typing issue.