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 s
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 Contin
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,e
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 node
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 nodes
> are instances of _ast.AST.
>
> > I don
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
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
> > corres
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;
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)
{
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
> writ
Greg Ewing schrieb:
> 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 it's generated code. It ha
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
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
a
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 string
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
___
Pyth
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
> t
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 t
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 _fields attribute on some AST nodes is
None; if this was do
18 matches
Mail list logo
