Re: [Python-Dev] Recent experience with the _ast module

2007-02-17 Thread Martin v. Löwis
Collin Winter schrieb: But Pass, Break, Continue and Ellipsis aren't in the same category as Add, Mult, Div, etc.. The former stand alone That's not true. Pass, Break, Continue don't stand alone; they are members of the body sequence of some other statement (in particular for Break and

Re: [Python-Dev] Recent experience with the _ast module

2007-02-17 Thread Collin Winter
On 2/17/07, Martin v. Löwis [EMAIL PROTECTED] wrote: Collin Winter schrieb: But Pass, Break, Continue and Ellipsis aren't in the same category as Add, Mult, Div, etc.. The former stand alone That's not true. Pass, Break, Continue don't stand alone; they are members of the body sequence of

Re: [Python-Dev] Recent experience with the _ast module

2007-02-16 Thread Brett Cannon
On 2/16/07, Collin Winter [EMAIL PROTECTED] wrote: On 2/14/07, Martin v. Löwis [EMAIL PROTECTED] 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

Re: [Python-Dev] Recent experience with the _ast module

2007-02-16 Thread Collin Winter
On 2/16/07, Brett Cannon [EMAIL PROTECTED] wrote: On 2/16/07, Collin Winter [EMAIL PROTECTED] wrote: On 2/14/07, Martin v. Löwis [EMAIL PROTECTED] wrote: Collin Winter schrieb: What's inconsistent about it? That classes are being used for the _ast.{Add,Sub,Mult,etc} names?

Re: [Python-Dev] Recent experience with the _ast module

2007-02-14 Thread Martin v. Löwis
Collin Winter schrieb: 2) It turned out that {BinOp, BoolOp,AugAssign,etc}.op were already singleton instances of their respective classes. I've changed asdl_c.py to no longer emit the *_singleton names and to use the corresponding *_type types in their place, which will enable me to write

Re: [Python-Dev] Recent experience with the _ast module

2007-02-14 Thread Martin v. Löwis
Greg Ewing schrieb: It would seem even easier (and a lot faster) to use an array to go from C enum -- some object, which could as well be an interned string as anything else. Have you actually looked at the code? How could it be faster than PyObject* ast2obj_boolop(boolop_ty o) {

Re: [Python-Dev] Recent experience with the _ast module

2007-02-14 Thread Greg Ewing
Martin v. Löwis wrote: switch(o) { case And: Py_INCREF(And_singleton); return And_singleton; case Or: Py_INCREF(Or_singleton); return Or_singleton; Well,

Re: [Python-Dev] Recent experience with the _ast module

2007-02-14 Thread Collin Winter
On 2/14/07, Martin v. Löwis [EMAIL PROTECTED] wrote: Collin Winter schrieb: 2) It turned out that {BinOp, BoolOp,AugAssign,etc}.op were already singleton instances of their respective classes. I've changed asdl_c.py to no longer emit the *_singleton names and to use the corresponding

Re: [Python-Dev] Recent experience with the _ast module

2007-02-14 Thread Martin v. Löwis
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

Re: [Python-Dev] Recent experience with the _ast module

2007-02-13 Thread Greg Ewing
Brett Cannon wrote: On 2/12/07, Collin Winter [EMAIL PROTECTED] wrote: 2) {BinOp,AugAssign,BoolOp,etc}.op I can't think of a reason, off the top of my head, why they can't be singletons. Why not just use interned strings? -- Greg ___ Python-Dev

Re: [Python-Dev] Recent experience with the _ast module

2007-02-13 Thread Brett Cannon
On 2/13/07, Greg Ewing [EMAIL PROTECTED] wrote: Brett Cannon wrote: On 2/12/07, Collin Winter [EMAIL PROTECTED] wrote: 2) {BinOp,AugAssign,BoolOp,etc}.op I can't think of a reason, off the top of my head, why they can't be singletons. Why not just use interned strings? Because the

Re: [Python-Dev] Recent experience with the _ast module

2007-02-13 Thread Collin Winter
On 2/12/07, Brett Cannon [EMAIL PROTECTED] wrote: They all sound reasonable. And it's nice to have a wanted feature be found from actual use. =) I've just uploaded patch #1659410 to SF, implementing the changes I outlined: 1) I changed some of the code emitted by asdl_c.py so _fields is

Re: [Python-Dev] Recent experience with the _ast module

2007-02-13 Thread Greg Ewing
Brett Cannon wrote: Because the AST code at the C level represent the 'op' value as basically an enumeration value, not a string. So creating an object is somewhat easier then trying to do the conversion to an interned string. It would seem even easier (and a lot faster) to use an array to

Re: [Python-Dev] Recent experience with the _ast module

2007-02-12 Thread Brett Cannon
On 2/12/07, Collin Winter [EMAIL PROTECTED] wrote: I've been working this past week at converting the stdlib's compiler package to use 2.5's new _ast module instead of the package's own AST. Overall, _ast was a joy to work with, save for the following nitpicks: 1) There are times when the

Re: [Python-Dev] Recent experience with the _ast module

2007-02-12 Thread Martin v. Löwis
Collin Winter schrieb: 1) There are times when the _fields attribute on some AST nodes is None; if this was done to indicate that a given node has no AST-related attributes, it would be much easier if _fields was [] in this case. As it is, I had to special-case node._fields is None in the