dalejung / asttools Goto Github PK

https://www.python.org/dev/peps/pep-0511/

This is part of a series of PEPs for a python static optimizer: http://faster-cpython.readthedocs.org/fat_python.html

Perhaps you could provide feedback or assistance given your relevant experience. Hopefully it will make stuff like this and delayed eval emulation easier.

Use same strategy as IPython here. We already keep the code string around.

Right now I just have a location dict with parent, field_name, field_index. Thinking of just making that an object and letting stuff like replace_node accept it.

The Call node no longer has a kwargs attribute. Something like:

ast.parse("test(**locals())")

Will put the locals() call into the Call.keywords array. The only difference between the kwargs in 3.4 and keywords in 3.5 is that the stararg will create a ``ast.keyword(arg=None, value=ast.Call(func=Name(id='locals'))`

Since with can have multiple with items, should we just match on a subset? Should:

with hello():
  _any_

match

with hello(), hi():
  pass

Or should the template default to strict and require an additional sentinel? like

with hello(), _any_:
  _any_

Thinking of creating an AST replacement that does things like keep track of parent and stuff. The custom AST would have the ability to extract a real ast. I suppose you run into an issue where you can't have the same Node in two different tree/placements, but really who cares?

My main annoyance right now with regular ast is that I have to keep a node context object around. Also an expanded AST would allow SyntaxError objects.

I currently use ArgSpec to munge both definitions and calls to a common type of format. In a lot of cases,

def bob(kw=1, *args):
    pass

and

bob(kw=1, *args)

Are useful to be parsed into a common format so I can quickly get the defined keywords plus any special args.

With 3.5, the difference between definitions and calling are much different due to various unpacking shortcuts. So it would make sense to kind of create an abstraction here that accomodates those difference but still allows me to use a common interface while dealing with the args.

Plus, with the differences between 3.4 and 3.5, I'd need something to buffer me from the underlying implementation. This goes a long with the creating my own ast issue. #2

Right now, I pretty much only support 3.5, after having only support 3.4. Personally IDC, but at some point I'd like to clean this up.