AFAIK the AST is
CPython-specific so should be treated with the same attitude as
changes to the bytecode. That means, do it conservatively, since there
*are* people who like to write tools that manipulate or analyze this,
and while they know they're doing something CPython and
2011/4/7 Maciej Fijalkowski fij...@gmail.com:
AFAIK the AST is
CPython-specific so should be treated with the same attitude as
changes to the bytecode. That means, do it conservatively, since there
*are* people who like to write tools that manipulate or analyze this,
and while they know
On Tue, Apr 5, 2011 at 6:37 AM, Nick Coghlan ncogh...@gmail.com wrote:
1. Making docstring an attribute of the Function node rather than
leaving it embedded as the first statement in the suite (this avoids
issues where AST-based constant folding could potentially corrupt the
docstring)
2.
Ok, so it sounds like ast is *not* limited to CPython? That makes it
harder to justify changing it just so as to ease the compilation
process in CPython (as opposed to add new language features).
I propose a different view: the AST *is* implementation specific,
although implementations are
Add py.test as an application that uses the AST to support Jython,
PyPy and CPython in a portable way. I always assumed AST was created
*because* bytecode was too CPython specific (but then I've never
implemented a language).
Historically, that's incorrect. The AST structure was introduced
On Tue, Apr 5, 2011 at 7:49 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Historically, that's incorrect. The AST structure was introduced to
simplify the implementation of (C)Python. Exposing it to Python modules
was done primarily because it's neat and was easy to do - not because
any
Nick Coghlan wrote:
1. Making docstring an attribute of the Function node rather than
leaving it embedded as the first statement in the suite (this avoids
issues where AST-based constant folding could potentially corrupt the
docstring)
2. Collapsing Num, Str, Bytes, Ellipsis into a single
As a user of the AST, I as well favor just changing the AST and the
version. IMHO, it is not intended to be stable between Python
releases (similar to bytecode).
Neil
___
Python-Dev mailing list
Python-Dev@python.org
On 4/3/2011 10:02 PM, Guido van Rossum wrote:
Sure, but do we have any indication that the warnings for dis make a difference?
I think there had been a few grumbles about bytecode not being stable.
Without that, it is part of the newish effort to specify in the docs
what is CPython
As a re-implementor of ast.py that tries to be node for node
compatible, I'm fine with #1 but would really like to have tests that
will fail in test_ast.py to alert me!
-Frank
___
Python-Dev mailing list
Python-Dev@python.org
On 04/04/2011 18:05, fwierzbi...@gmail.com wrote:
As a re-implementor of ast.py that tries to be node for node
compatible, I'm fine with #1 but would really like to have tests that
will fail in test_ast.py to alert me!
A lot of tools that work with Python source code use ast - so even
though
On Mon, Apr 4, 2011 at 10:05 AM, fwierzbi...@gmail.com
fwierzbi...@gmail.com wrote:
As a re-implementor of ast.py that tries to be node for node
compatible, I'm fine with #1 but would really like to have tests that
will fail in test_ast.py to alert me!
[and]
On Mon, Apr 4, 2011 at 10:38 AM,
On Apr 4, 2011, at 2:00 PM, Guido van Rossum wrote:
On Mon, Apr 4, 2011 at 10:05 AM, fwierzbi...@gmail.com
fwierzbi...@gmail.com wrote:
As a re-implementor of ast.py that tries to be node for node
compatible, I'm fine with #1 but would really like to have tests that
will fail in test_ast.py
Guido wrote:
On Mon, Apr 4, 2011 at 10:05 AM, fwierzbi...@gmail.com
fwierzbi...@gmail.com wrote:
As a re-implementor of ast.py that tries to be node for node
compatible, I'm fine with #1 but would really like to have tests that
will fail in test_ast.py to alert me!
[and]
On Mon, Apr
On 4 April 2011 19:07, Glyph Lefkowitz gl...@twistedmatrix.com wrote:
On Apr 4, 2011, at 2:00 PM, Guido van Rossum wrote:
On Mon, Apr 4, 2011 at 10:05 AM, fwierzbi...@gmail.com
fwierzbi...@gmail.com wrote:
As a re-implementor of ast.py that tries to be node for node
compatible, I'm fine
On 4/4/2011 2:00 PM, Guido van Rossum wrote:
On Mon, Apr 4, 2011 at 10:05 AM, fwierzbi...@gmail.com
fwierzbi...@gmail.com wrote:
As a re-implementor of ast.py that tries to be node for node
compatible, I'm fine with #1 but would really like to have tests that
will fail in test_ast.py to alert
Terry wrote:
Are at least some of the implementation methods similar enough that they
could use the same AST? It is, after all, a *semantic* translation into
another
language, and that need not depend on subsequent transforation and
compilation to the ultimate target. A
On Mon, Apr 4, 2011 at 12:56 PM, Terry Reedy tjre...@udel.edu wrote:
Moving optimizations from bytecode (where they
are demonstrably a bit fragile) to ast manipulations (where we presume they
will be more robust and can be broader) should be a win in itself
I am still doubtful of that. While
On 4/4/2011 4:05 PM, Dino Viehland wrote:
reduce to the core DLR nodes on-demand). We already do a huge amount of
manipulation of those ASTs from optimizations (constant folding being the
primary
one) to re-writing them completely for things like generators or sys.settrace
support and
other
Ok, so it sounds like ast is *not* limited to CPython? That makes it
harder to justify changing it just so as to ease the compilation
process in CPython (as opposed to add new language features).
The changes above are not just for CPython, but to simplify processing
of AST in general, by
On Sun, Apr 3, 2011 at 3:42 PM, Eugene Toder elto...@gmail.com wrote:
If it's do-able, your option 2 is probably the way to go. Out of the
box, it may just need to raise an exception if asked to down-convert
code that uses new constructs that can't readily be expressed using
the old AST (I'm
1. Do nothing. This will break code that currently uses AST, but doesn't add
any complexity to cpython.
I'm in favor of this approach as well. Notice that there is
ast.__version__ precisely so that applications can support multiple AST
versions.
Regards,
Martin
On 3 April 2011 07:55, Martin v. Löwis mar...@v.loewis.de wrote:
1. Do nothing. This will break code that currently uses AST, but doesn't add
any complexity to cpython.
I'm in favor of this approach as well. Notice that there is
ast.__version__ precisely so that applications can support
On Sun, Apr 3, 2011 at 4:17 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 3 April 2011 07:55, Martin v. Löwis mar...@v.loewis.de wrote:
1. Do nothing. This will break code that currently uses AST, but doesn't add
any complexity to cpython.
I'm in favor of this approach as well. Notice that
On Sat, Apr 2, 2011 at 23:55, Martin v. Löwis mar...@v.loewis.de wrote:
1. Do nothing. This will break code that currently uses AST, but doesn't
add
any complexity to cpython.
I'm in favor of this approach as well. Notice that there is
ast.__version__ precisely so that applications can
On Mon, Apr 4, 2011 at 5:11 AM, Guido van Rossum gu...@python.org wrote:
In the mean time, until we hear differently, I'm also in favor of #1
(do nothing). I would (perhaps redundantly) say that such changes
should only go into new major releases (i.e. 3.3 right now), not
backported into
On Sun, Apr 3, 2011 at 6:43 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Mon, Apr 4, 2011 at 5:11 AM, Guido van Rossum gu...@python.org wrote:
In the mean time, until we hear differently, I'm also in favor of #1
(do nothing). I would (perhaps redundantly) say that such changes
should only go
On Mon, Apr 4, 2011 at 12:02 PM, Guido van Rossum gu...@python.org wrote:
Perhaps we should add a warning to the ast module docs similar to the
one we have for the dis module, and use it to explicitly remind people
to check ast.__version__ before proceeding with AST manipulation?
Sure, but do
On 4/2/2011 9:55 PM, Eugene Toder wrote:
Documentation for ast module does not warn about possible changes,
The current boxed warning at the top of the dis doc is fairly recent.
The ast doc should gain something similar. It currently does say:
__version__ which is the decimal Subversion
Hello,
While working on a rewrite of peephole optimizer that works on AST
(http://bugs.python.org/issue11549) I had to make a few changes to the
structure of AST. The changes are described in the issue. This raises the
question -- what is the policy for making changes to the AST? Documentation
2011/4/2 Eugene Toder elto...@gmail.com:
Hello,
While working on a rewrite of peephole optimizer that works on AST
(http://bugs.python.org/issue11549) I had to make a few changes to the
structure of AST. The changes are described in the issue. This raises the
question -- what is the policy
On Sun, Apr 3, 2011 at 12:07 PM, Benjamin Peterson benja...@python.org wrote:
Assuming we do want to make changes (not just extensions for new language
features), I see 3 options for handling them:
1. Do nothing. This will break code that currently uses AST, but doesn't add
any complexity to
However, I'm not sure we *can* do a general-purpose AST transformation
that handles both new nodes and changes to existing nodes correctly
for all applications.
As long as both versions contain the same information we can write a
transformation that does a near-perfect job.
E.g. for my changes
On Sun, Apr 3, 2011 at 2:24 PM, Eugene Toder elto...@gmail.com wrote:
However, I'm not sure we *can* do a general-purpose AST transformation
that handles both new nodes and changes to existing nodes correctly
for all applications.
As long as both versions contain the same information we can
If it's do-able, your option 2 is probably the way to go. Out of the
box, it may just need to raise an exception if asked to down-convert
code that uses new constructs that can't readily be expressed using
the old AST (I'm specifically thinking of the challenge of converting
PEP 380's
35 matches
Mail list logo
