[Python-Dev] Recent experience with the _ast module (original) (raw)
Collin Winter collinw at gmail.com
Sat Feb 17 02:19:24 CET 2007
- Previous message: [Python-Dev] Recent experience with the _ast module
- Next message: [Python-Dev] Recent experience with the _ast module
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 2/16/07, Brett Cannon <brett at python.org> wrote:
On 2/16/07, Collin Winter <collinw at gmail.com> wrote: > On 2/14/07, "Martin v. Löwis" <martin at v.loewis.de> wrote: > > Collin Winter schrieb: > > > What's inconsistent about it? That classes are being used for the > > > ast.{Add,Sub,Mult,etc} names? > > > > Exactly. These aren't names - they are nodes in the tree. All nodes > > are instances of ast.AST. > > > > > I don't see the need for both ast.Add and ast.Add.singleton or > > > ast.add or however else it might be spelled. I'd be perfectly happy > > > doing something like "ast.Add = object()" (when initializing the ast > > > module), so long as I can write "node.op is ast.Add", "node.op == > > > ast.Add", or something equally brief and to-the-point. > > > > Would you like to do the same for Pass, Break, Continue, and Ellipsis? > > > > They are also "just names". If you make ast.Add the entry in the > > tree itself, why not ast.Break? Or, if you have a way to deal with > > ast.Break, why can't the same way work for ast.Add? > > But Pass, Break, Continue and Ellipsis aren't in the same category as > Add, Mult, Div, etc.. The former stand alone, while the only time > you'll ever encounter Add, Mult, Mod and co. is in the context of a > BoolOp, BinOp or whatever. I could of course add separate visitor > methods for each op type to my code generator, but that's a lot of > boilerplate code for very little gain. I could use a dispatch table in > visitBoolOp, and dispatch like "dispatch[type(node.op)]", but why? In > this scenario, node.op doesn't convey any information other than its > type. Add, Mult, etc are just values in an enumeration, so why not > treat them that way and be able to write "dispatch[node.op]". > > So: what if ast.Add and co. were singleton instances of ast.AST or > even of a subclass of AST, like ast.Op? That way, we keep the > consistency that all AST nodes are instances of ast.AST and I get the > nice property I'm looking for, ie, "node.op is ast.Mult". >
If you look back in the history of this thread I think Martin suggested this: "I'd rather prefer if the singletons where exposed under a name, e.g. ast.Add.singleton, or ast.add (if that doesn't cause conflicts)." Since the both of you have proposed this I think this is the best way to move forward.
That's what I get for letting this thread drop for a few days.
I read Martin's original proposal as wanting to have _ast.add (singleton instance) in addition to _ast.Add (presumably the class of _ast.add). To be clear, I want to replace the current _ast.Add (a class, subclassing AST) with an instance of _ast.Op or something comparable; making _ast.{Load,Store,Del,AugLoad,AugStore,Param} into instances of an _ast.Context class would be a part of this.
Collin Winter
- Previous message: [Python-Dev] Recent experience with the _ast module
- Next message: [Python-Dev] Recent experience with the _ast module
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]