Brett Cannon wrote:
If the compiler was hacked on by more people I would agree with this.
But few people do
This has the potential to be a self-perpetuating situation.
There may be few people hacking on it now, but more people
may want to in the future. Those people may look at the
funky
As per Neal's prodding email, here is a thread to discuss where we
want to go with the C AST to Python stuff and what I think are the
core issues at the moment.
First issue is the ast-objects branch. Work is being done on it, but
it still leaks some references (Neal or Martin can correct me if I
Greg Ewing wrote:
Brett Cannon wrote:
One protects us from ending up with an unusable AST since
the seralization can keep the original AST around and if the version
passed back in from Python code is junk it can be tossed and the
original version used.
I don't understand why this is an
Thomas Wouters wrote:
On Wed, Feb 15, 2006 at 07:28:36PM +1000, Nick Coghlan wrote:
On the 'unusable AST' front, if AST transformation code creates illegal
output, then the main thing is to raise an exception complaining about
what's wrong with it. I believe that may need a change to the
On Wed, 15 Feb 2006 00:34:35 -0800
Brett Cannon [EMAIL PROTECTED] wrote:
As per Neal's prodding email, here is a thread to discuss where we
want to go with the C AST to Python stuff and what I think are the
core issues at the moment.
First issue is the ast-objects branch. Work is being
I am still -1 on the ast-objects branch. It adds a lot of boilerplate
code and its makes complicated what is now simple. I'll see if I can
get a rough cut of the marshal code ready today, so there will be a
complete implementation of my original plan.
I also think we should keep the
On Wed, Feb 15, 2006 at 10:29:38AM -0500, Jeremy Hylton wrote:
Unfortunately, the compiler talk isn't until the last day and I can't
stay for sprints. It would be better to have the talk, then the open
space, then the sprint.
If you mean Implementation of the Python Bytecode Compiler, that's
On Wed, 2006-02-15 at 00:34 -0800, Brett Cannon wrote:
I personally think we should choose an initial global access API to
the AST as a starting API. I like the sys.ast_transformations idea
since it is simple and gives enough access that whether read-only or
read-write is allowed something
Thomas Wouters wrote:
I would personally prefer the AST validation to be a separate part of the
compiler. It means the one or the other can be out of sync, but it also
means it can be accessed directly (validating AST before sending it to the
compiler) and the compiler (or CFG generator, or
On 2/15/06, Barry Warsaw [EMAIL PROTECTED] wrote:
I haven't been following the AST stuff closely enough, but I'm not crazy
about putting access to this in the sys module. It seems like it
clutters that up with a name that will be rarely used by the average
Python programmer.
Agreed. I'm
On 2/15/06, Jeremy Hylton [EMAIL PROTECTED] wrote:
[SNIP]
How about we arrange for some open space time at PyCon to discuss?
Unfortunately, the compiler talk isn't until the last day and I can't
stay for sprints. It would be better to have the talk, then the open
space, then the sprint.
I
On 2/15/06, Nick Coghlan [EMAIL PROTECTED] wrote:
Greg Ewing wrote:
Brett Cannon wrote:
One protects us from ending up with an unusable AST since
the seralization can keep the original AST around and if the version
passed back in from Python code is junk it can be tossed and the
On 2/15/06, Nick Coghlan [EMAIL PROTECTED] wrote:
Thomas Wouters wrote:
On Wed, Feb 15, 2006 at 07:28:36PM +1000, Nick Coghlan wrote:
On the 'unusable AST' front, if AST transformation code creates illegal
output, then the main thing is to raise an exception complaining about
what's
13 matches
Mail list logo
