[Python-3000] pep 3124 plans

Joe Smith unknown_kev_cat at hotmail.com
Sat Jul 21 19:07:12 CEST 2007


"Guido van Rossum" <guido at python.org> wrote in message 
news:ca471dc20707210816r4d663cdaqcef7e9f28c150a75 at mail.gmail.com...
> On 7/21/07, Joe Smith <unknown_kev_cat at hotmail.com> wrote:
>> One of the nice features of Eby's proposal is that more complicated
>> dispatching systems can be added. Perhaps some application needs a
>> dispatching engine that can dispatch based on the value of an objects
>> member. Perhaps the user wants an overload specificly for any product 
>> object
>> whose price property equals 0. With Eby's system adding a dispatch engine
>> that supports that is not difficult.
>
> This is true. However it comes at a cost. Whenever I see an API that
> takes a string which is then parsed by the called function as a Python
> expression (perhaps constrained to a subset of Python) I cringe,
> especially if the common use is to pass a literal. There are just so
> many issues with that... It's not colorized by the editor, it's not
> syntax-checked by either the editor or the Python parser, it requires
> one to build yet another parser...
>
> This is why I don't like the ...when("isinstance(obj, list)") syntax
> from (I think) RuleDispatch, and I'm glad it's not in the PEP. I'm
> unclear however on how you would do this otherwise -- is overloading
> implies() the best approach?

First of all, If i understrand the PEP correectly. that should be:
when(funcname,"isinstance(obj, list)") where funcname is the name of the 
function to be overloaded.


Whatever dispatch engine that is, is it not possible to do something more 
like
when(funcname,{isinstance,{obj,list}))? (I used list syntax here as an 
example only (other syntaxes could work). I'm not sure if the 'obj' part is
refering to a variable that would be in scope at the when declaration. That 
might have to be quoted as a string.

Regardless though, I'm pretty sure dispatch engines can use things other 
than interpreted strings. 




More information about the Python-3000 mailing list