[Python-3000] pep 3124 plans (original) (raw)

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 <unknownkevcat 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.

More information about the Python-3000 mailing list