[Python-3000] Abilities / Interfaces

[Guido van Rossum]

On 11/22/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 10:43 AM 11/22/2006 -0800, Guido van Rossum wrote:
> >There is a dangerous amount of content-free rhetoric in this thread.
>
> Actually, I think that some of my statements are being misunderstood as
> such, when I'm intending only to describe *how* interfaces (or inspection)
> can be *derived* from generic functions.  When I say that these other
> concepts are "unnecessary", I mean that they can be derived from generics,
> and that the reverse is not true.
>
> This isn't rhetoric, IMO, and it's not about religion or purity, but about
> practicalities.  Often, an interface consists of just one operation, so
> treating interfaces as fundamental introduces additional "unnecessary"
> complexity in those cases, whereas being able to treat that one-operation
> interface as a single generic function removes the need for interfaces --
> even as a *concept* to be understood, let alone implemented.  That's the
> power of Python's existing generics: they don't rely on you "implementing
> the iterable interface", but just on defining the iter() *operation*.
>
>
> >As I've tried to mention through examples, there are plenty of
> >situations where a carefully placed if-then is a lot more practical
> >than adding a new method to some remote class (or several).
>
> Absolutely.  I am saying only that the inspection can be implemented *in
> terms of* generic functions.
>
>
> >But even the best generic function API I've seen is a lot
> >more verbose than this -- there seems to be a separate set-up
> >involved.
>
> Actually, my 'defop' proposal would allow you to do this:
>
>      def sendmail(...):
>          # default case
>
>      defop sendmail(...):
>          # special case, w/additional type info in arg signature
>
> The first statement creates a function called 'sendmail', and the
> subsequent statement overloads it.  Of course, I suppose 'defop' could also
> be spelled differently to emphasize the difference, e.g.:
>
>      def sendmail(...):
>          # default case
>
>      overload sendmail(...):
>          # special case, w/additional type info in arg signature

It's important for my understanding to show what's on the dots and
also how defop is implemented. See another thread. Right now, while
not rhetoric, the above examples are indistinguishable from magic to
me (I hope you recognize the quote).

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)