[Python-3000] pep 3124 plans
Phillip J. Eby
pje at telecommunity.com
Sat Jul 21 19:33:08 CEST 2007
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
>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.
More information about the Python-3000