[Python-3000] Abilities / Interfaces

[Phillip J. Eby]

At 01:00 PM 11/22/2006 -0800, Guido van Rossum wrote:
>On 11/22/06, Phillip J. Eby <pje at telecommunity.com> wrote:
>>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.

The defop questions are now answered in that thread.  Regarding the dots, I 
meant them to refer to the Java-style overload example that came 
previously, assuming the use of a multi-dispatch overload implementation 
like your type-tuple prototype of earlier this year, using the optional 
type declaration syntax to describe the overloaded properties.  IOW:

     def sendmail(self, from_addr, to_addrs, msg, mail_options=[],
                  rcpt_options=[]):
         # default implementation

     overload sendmail(self, from_addr, to_addrs:str, msg,
                       mail_options=[], rcpt_options=[]):
         self.sendmail(from_addr, [to_addrs], msg, mail_options, rcpt_options)

While this is more verbose than sticking an 'if' into the original 
sendmail(), note that it can also be added by a third party, via:

     overload smtpblib.SMTP.sendmail(
         self, from_addr, to_addrs:str, msg,
         mail_options=[], rcpt_options=[]
     ):
         self.sendmail(from_addr, [to_addrs], msg, mail_options, rcpt_options)

So, someone who didn't want to wait for the patch to add your "if" could 
just add their own fix on the fly.  :)


>  Right now, while
>not rhetoric, the above examples are indistinguishable from magic to
>me (I hope you recognize the quote).

The problem I have sometimes in making my proposals clear to you is that, 
at the level of abstraction I think on, there are often multiple ways to 
carry out a useful/usable implementation, but you seem to want to 
understand one *particular* implementation, even though I'm trying to 
propose an approach to the solution, rather than a particular solution.

However, when I present you with a particular implementation, you then pick 
holes in the implementation itself, or the tradeoffs made to render the 
example simple.  If I knew what tradeoffs you would prefer ahead of time, 
then I could make my examples match the desired tradeoffs, but in the 
absence of that information I can only fall back to describing a general 
concept.  So we tend to go back and forth between abstractions rejected for 
lack of specificity, and specific things rejected for their particular 
nature.  :)  Perhaps I should try giving implementations explicitly 
labelled as prototypes and stating that there are other ways to do the same 
thing?