Python and generic programming

[Roman Suzi]

On Fri, 22 Oct 2004, Jeremy Bowers wrote:

> 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.

Thank you for pointing this out: I was mailing from unusual account.

> 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.)

Google gives

http://www.cs.rpi.edu/~musser/gp/

> 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.)

That is, Python supports generic programming paradigm while (like in C++)
much is left to the discipline of programmer.

> 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.

I am no expert too. That was the reason to ask here in the first place ;-)

> --
> http://mail.python.org/mailman/listinfo/python-list

Sincerely yours, Roman A.Suzi
-- 
 - Petrozavodsk - Karelia - Russia - mailto:rnd at onego.ru -