[Python-3000] pep 3124 plans

[Phillip J. Eby]

At 08:16 AM 7/21/2007 -0700, Guido van Rossum wrote:
>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,

Note that it's been previously proposed to add an AST literal syntax 
for "quoting" code to get around this, but such metasyntactic 
features were rejected for 3.0.

There are other applications for such a syntax besides generic 
functions: there exist today Python ORMs that translate Python 
generator expressions to SQL queries.  Today, they work by 
decompiling bytecode, precisely to avoid some of the issues you 
mention.  However, an AST literal syntax would actually work better 
for that, IMO, just as it would for generic functions.


>  it requires
>one to build yet another parser...

Well, for Python and subsets thereof, it suffices to use the stdlib 
for that.  My implementations use the tuple-formatted ASTs from the 
'parser' module.


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

It's one approach.  However, the idea of "@when" and other decorators 
in the PEP taking a second argument is so that you can pass in 
objects of your own design.  These objects can implement disjuncts() 
to support or-ed conditions, and can request an upgrade to a 
different dispatching engine.

Of course, the ability to pass in such objects means you could pass 
in something like "Expr('some python expression')"...  which was of 
course one thing I planned to use it for.