On 2/16/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Whereas if there weren't any funky coding style in the
> first place, more potential compiler hackers might be
> encouraged to have a go.
I'm trying to make the code simple. The style of code is different
than other parts of Python, but a compil
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 cod
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
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
On 2/15/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> 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
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.
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.
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 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 somethin
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", tha
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 transformati
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 bei
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
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 compiler
> whether the mo
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
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 issue. If Python code
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
17 matches
Mail list logo
