[Python-3000] Abilities / Interfaces and security

[Tim Hochberg]

Jim Jewett wrote:
> On 11/22/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> 
>> 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.  :)
> 
> Hey, cool, can I also do
> 
>     overload smtplib.SMTP.sendmail(self, from_addr:str, to_addrs:str, msg, ...)
>         if stalkee == from_addr:
>             archive_and_randomly_rewrite_before_sending(...)
> 
> Since this is more specific on the from_addr, it should always be called.

I suppose this issue may be real, but this example seems like FUD; for 
most classes I can completely override the behavior today simply by 
monkey patching the method and this isn't typeically a problem that we see:

	smtplib.SMTP.sendmail = my_bogus_sendmail_function

> 
> Also, can I
> 
>     overload __builtins__.str(arg:object)
> 
> to effectively extend (or replace) the builtin type?
> 
> There is certainly value in open classes, and it can make writing code
> easier. 

This isn't about open/closed classes except incidentally is it? It's 
really about open/closed functions and methods.

  But it can also make maintaining code much harder.  Today,
> almost all classes are open, but those coded in C are typically closed
> -- and Brett is relying on this for security.
> How-it-happened-to-be-implemented may not be the best way to decide
> open/closed, but I think there needs to be *some* way of keeping a
> class closed.

I would expect that either functions would default to closed and you 
would get a generic function with an appropriate decorator, or functions 
would default to open and you could instead close them, again with an 
appropriate decorator. To be concrete, either:

     def my_closed_function(arg):
         #....

     @overloadable
     def my_open_function(arg):
         #....
     overload my_open_function(arg:str):
        #....

or:

     @closed  #final? nonoverloadable?
     def my_closed_function(arg):
         #....

     def my_open_function(arg):
         #....
     overload my_open_function(arg:str):
         #....

Either way, this doesn't look like a big deal. I'm more interested in 
having, for debugging purposes, a way to do some introspection on 
generic functions. For instance, finding out what function would be 
called for a given set of arguments and perhaps some information on why 
that match was chosen. Also, what overloads are set up and with what 
signatures.

-tim