Re: [Python-Dev] a Python interface for the AST (WAS: DRAFT: python-dev...)

2005-11-23 Thread Brett Cannon
On 11/23/05, Greg Ewing [EMAIL PROTECTED] wrote:
 Brett Cannon wrote:

  There are two problems to this topic; how to
  get the AST structs into Python objects and how to allow Python code
  to modify the AST before bytecode emission

 I'm astounded to hear that the AST isn't made from
 Python objects in the first place. Is there a particular
 reason it wasn't done that way?


I honestly don't know, Greg.  All of the structs are generated by
Parser/asdl_c.py which reads in the AST definition from
Parser/Python.asdl .  The code that is used to allocate and initialize
the structs is in Python/Python-ast.c and is also auto-generated by
Parser/asdl_c.py .

I am guessing here, but it might have to do with type safety.  Some
nodes can be different kinds of subnodes (like the stmt node) and thus
are created using a single struct and a bunch unions internally.  So
there is some added security that stuff is being done correctly.

Otherwise memory is the only other reason I can think of.  Or Jeremy
just didn't think of doing it that way when this was all started years
ago.  =)  But since it is all auto-generated it should be doable to
make them Python objects.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] a Python interface for the AST (WAS: DRAFT: python-dev...)

2005-11-22 Thread Steven Bethard
I wrote (in the summary):
 While there is no interface to the AST yet, one is
 intended for the not-so-distant future.

Simon Burton wrote:
 who is doing this ? I am mad keen to get this happening.

Brett Cannon wrote:
 No one yet.  Some ideas have been tossed around (read the thread for
 details), but no one has sat down to hammer out the details.  Might
 happen at PyCon.

Simon Burton wrote:
 Yes, i've been reading the threads but I don't see anything
 about a python interface. Why I'm asking is because I could
 probably convince my employer to let me (or an intern) work
 on it. And pycon is not until febuary. I am likely to start
 hacking on this before then.

Basically, all I saw was your post asking for a Python interface[1],
and a few not yet responses.  I suspect that if you were to
volunteer to head up the work on the Python interface, no one would be
likely to stop you. ;-)

[1]http://mail.python.org/pipermail/python-dev/2005-October/057611.html

Steve
--
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] a Python interface for the AST (WAS: DRAFT: python-dev...)

2005-11-22 Thread Neal Norwitz
On 11/22/05, Brett Cannon [EMAIL PROTECTED] wrote:

 But if I had my way I think that having all AST objects be PyObjects
 and then providing support for all three ways of getting access to the
 AST (command-line, sys iterable, function for specific code object)
 would be fantastic.

There needs to be a function that takes a filename (or string of code)
and returns an AST.  Hmm, it would be nice to give a function a module
name (like from an import statement) and have Python resolve it using
the normal sys.path iteration.

n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] a Python interface for the AST (WAS: DRAFT: python-dev...)

2005-11-22 Thread Brett Cannon
On 11/22/05, Neal Norwitz [EMAIL PROTECTED] wrote:
 On 11/22/05, Brett Cannon [EMAIL PROTECTED] wrote:
 
  But if I had my way I think that having all AST objects be PyObjects
  and then providing support for all three ways of getting access to the
  AST (command-line, sys iterable, function for specific code object)
  would be fantastic.

 There needs to be a function that takes a filename (or string of code)
 and returns an AST.

Yes and I guess.  =)  I can see the filename to check a module
useful for stuff like PyChecker.  But for a string of code, I don't
think it would be that critical; if you provide a way to get the AST
for a code object you can just pass the string to compile() and then
get the AST from there.

  Hmm, it would be nice to give a function a module
 name (like from an import statement) and have Python resolve it using
 the normal sys.path iteration.


Yep, import path - filename path would be cool.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] a Python interface for the AST (WAS: DRAFT: python-dev...)

2005-11-22 Thread Phillip J. Eby
At 06:32 PM 11/22/2005 -0800, Brett Cannon wrote:
   Hmm, it would be nice to give a function a module
  name (like from an import statement) and have Python resolve it using
  the normal sys.path iteration.
 

Yep, import path - filename path would be cool.

Zipped and frozen modules don't have filename paths, so I'd personally 
rather see fewer stdlib modules making the assumption that modules are 
files.  Instead, extensions to the PEP 302 loader protocol should be used 
to support introspection, assuming there aren't already equivalent 
capabilities available.  For example, PEP 302 allows a 'get_source()' 
method on loaders, and I believe the zipimport loader supports that.  (I 
don't know about frozen modules.)

The main barrier to this being really usable is the absence of loader 
objects for the built-in import process.  This was proposed by PEP 302, but 
never actually implemented, probably due to time constraints on the Python 
2.3 release schedule.

It's relatively easy to implement this missing loader class in Python, 
though, and in fact the PEP 302 regression test in the stdlib does exactly 
that.  Some work, however, would be required to port this to C and expose 
it from an appropriate module (imp?).

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com