CPython 2.5, which will be released Real Soon Now, is the first version to ship with new "AST branch", which have been in development for a long time. AST branch uses ASDL, Abstract Syntax Description Language http://asdl.sourceforge.net/ to describe Abstract Syntax Tree data structure used by CPython compiler. In theory this is language independant, and the same file could be used to generate C# source files. Having the same AST for Python implementations will be good for applications and libraries using Python implementations's internal parsers and compilers. Currently, those using CPython parser module or compiler package can't be easily ported to IronPython. What do you think? -- Seo Sanghyeon
On 9/13/06, Sanghyeon Seo <sanxiyn@gmail.com> wrote:
It would be nice, but see below. Having the same AST for Python implementations will be good for
I have talked to Jim Hugunin about this very topic at the last PyCon. He pointed out that IronPython was started before he knew about the AST branch so that's why he didn't use it. Plus, by the time he did know, it was too late to switch right then and there. As for making the AST branch itself more of a standard, I have talked to Jeremy Hylton about that and he didn't like the idea, at least for now. The reasons for keeping it as "experimental" in terms of exposure at the Python level is that we do not want to lock ourselves down to some AST spec that we end up changing in the future. It's the same reasoning behind not officially documenting the marshal format; we want the flexibility. How best to resolve all of this, I don't know. I completely understand not wanting to lock ourselves down to an AST too soon. Might need to wait a little while after the AST has been out in the wild to see what the user response is and then make a decision. -Brett
Brett Cannon wrote:
One of the biggest issues I have with the current AST is that I don't believe it really gets the "slice" and "extended slice" terminology correct (it uses 'extended slice' to refer to multi-dimensional indexing, but the normal meaning of that phrase is to refer to the use of a step argument for a slice [1]) Cheers, Nick. [1] http://www.python.org/doc/2.3.5/whatsnew/section-slices.html -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
On 9/17/06, Nick Coghlan <ncoghlan@gmail.com> wrote:
The two were introduced together and were referred to together as "extended slicing" at the time, so I'm not sure who is confused. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
Ah, that would explain it then - I first encountered the phrase 'extended slicing' in the context of the Python 2.3 additions to the builtin types, so I didn't realise it referred to all __getitem__ based non-mapping lookups, rather than just the start:stop:step form of slicing. Given that additional bit of history, I don't think changing the name of the AST node is worth the hassle - I'll just have to recalibrate my brain :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
On 9/13/06, Sanghyeon Seo <sanxiyn@gmail.com> wrote:
It would be nice, but see below. Having the same AST for Python implementations will be good for
I have talked to Jim Hugunin about this very topic at the last PyCon. He pointed out that IronPython was started before he knew about the AST branch so that's why he didn't use it. Plus, by the time he did know, it was too late to switch right then and there. As for making the AST branch itself more of a standard, I have talked to Jeremy Hylton about that and he didn't like the idea, at least for now. The reasons for keeping it as "experimental" in terms of exposure at the Python level is that we do not want to lock ourselves down to some AST spec that we end up changing in the future. It's the same reasoning behind not officially documenting the marshal format; we want the flexibility. How best to resolve all of this, I don't know. I completely understand not wanting to lock ourselves down to an AST too soon. Might need to wait a little while after the AST has been out in the wild to see what the user response is and then make a decision. -Brett
Brett Cannon wrote:
One of the biggest issues I have with the current AST is that I don't believe it really gets the "slice" and "extended slice" terminology correct (it uses 'extended slice' to refer to multi-dimensional indexing, but the normal meaning of that phrase is to refer to the use of a step argument for a slice [1]) Cheers, Nick. [1] http://www.python.org/doc/2.3.5/whatsnew/section-slices.html -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
On 9/17/06, Nick Coghlan <ncoghlan@gmail.com> wrote:
The two were introduced together and were referred to together as "extended slicing" at the time, so I'm not sure who is confused. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
Ah, that would explain it then - I first encountered the phrase 'extended slicing' in the context of the Python 2.3 additions to the builtin types, so I didn't realise it referred to all __getitem__ based non-mapping lookups, rather than just the start:stop:step form of slicing. Given that additional bit of history, I don't think changing the name of the AST node is worth the hassle - I'll just have to recalibrate my brain :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
participants (4)
-
Brett Cannon -
Guido van Rossum -
Nick Coghlan -
Sanghyeon Seo