[Python-Dev] PyAST_FromNode returning PyTypeObject* ?
Neal,
Why did you suggest that PyAST_FromNode returns PyTypeObject*?
I can't see why type objects are much used in the AST, unless
I'm missing something essential.
Anyway, I started converting ast.c (two functions only), and
noticed that there is a convention to have nested variables
referring to fresh memory (e.g. inside switch statements). I
started changing these to have all variables at the toplevel.
Then, in either success or failure, you have to release all
of them. Unfortunately, sometimes in failure, an additional
function is called, which isn't called in success. So I
added a success: label.
Also, it is somewhat inconvenient that PyList_SET_ITEM
steals references. Currently, I INCREF the objects added
to the list (as the success: label will DECREF them);
alternatively, clearing the pointer to NULL might also
be appropriate. Perhaps we could have a STEAL_ITEM
macro inside ast.c:
#define STEAL_ITEM(list,index,variable) \
do{PyList_SET_ITEM(list,index,variable);variable=NULL;}while(0)
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Memory management in the AST parser & compiler
Martin v. Löwis wrote: > Nick Coghlan wrote: > > The ast C structs are already auto-generated by a Python script > (asdl_c.py, to > > be precise). The trick is to make that script generate full PyObjects > rather > > than the simple C structures that it generates now. > > See the ast-object branch. Thanks Martin. > > The second step is to then modify ast.c to use the new structures. A > branch > > probably wouldn't help much with initial development (this is a > "break the > > world, check in when stuff compiles again" kind of change, which is > hard to > > split amongst multiple people), but I think it would be of benefit when > > reviewing the change before moving it back to the trunk. > > Well, there would be a clear two-split right now: one could change > ast.c, and the other compile.c. I was focusing too much on the AST production end, and managed to forget that compile.c and symtable.c are consumers of the AST, so they'll likely care about the change as well ;) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ast-objects branch created
Martin, I'm not sure what your intent for this work is, but I'd like to create a parallel arena branch and compare the results. I'll start work on that tomorrow. Jeremy On 11/30/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > I created > > http://svn.python.org/projects/python/branches/ast-objects/ > > You can convert your repository to that branch with > > svn switch svn+ssh://[EMAIL PROTECTED]/python/branches/ast-objects > > in the toplevel directory. In particular, this features > > http://svn.python.org/projects/python/branches/ast-objects/Parser/asdl_c.py > http://svn.python.org/projects/python/branches/ast-objects/Include/Python-ast.h > http://svn.python.org/projects/python/branches/ast-objects/Python/Python-ast.c > > The status is currently this: > - asdl_c generates a type hierarchy: "Sum" productions have one type >per constructor, inheriting from a type for the sum; plain products >only have a type for the product. > - attributes are in the base type, accessible through o->_base.attr; >projections of the product types are accessible directly through >member names. > - all projections must be non-NULL. Sequences are represented through >potentially empty lists; optional types are potentially represented >through Py_None. bool is gone; use Py_True/Py_False. The only >primitive type remaining is int (which only occurs in lineno) > - the types currently have only a constructor, a dealloc function, >and an _Check macro. > - Naming is this: for cross-object-file visible symbols (functions >and global variables), a Py_ prefix is used. Otherwise, I use >the type name or constructor name directly. There is a #define >for the Py__New function, so you can also write (params). >Parameter order for the types is: projections first, then >attributes. > - For compatibility with the current code, the Sum base types >also have the _kind enumeration (although that appears not >to get initialized right now). > > For asdl_c, I see the following things as TODOs: > - add support for traversing the types from C, through tp_members >(read-only). Optionally add support for pickling. > - add support for garbage collection. I don't expect this to be >necessary right now, but will be if the API is exposed, and it >doesn't cost much. > > The bigger chunk of necessary changes is in using these, starting > with ast.c. > > Feel free to commit any changes to that branch that you consider > helpful. To avoid duplicated work, posting a note here might > also help. > > Regards, > Martin > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyAST_FromNode returning PyTypeObject* ?
On 12/1/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Neal, > > Why did you suggest that PyAST_FromNode returns PyTypeObject*? > I can't see why type objects are much used in the AST, unless > I'm missing something essential. It was late and I was trying to make progress. Assume it was a mistake. It doesn't seem to make much sense based on the name. I think I was replacing all mods with PyTypeObject, but since they are probably lists, PyObject would be correct. n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ast-objects branch created
On 12/1/05, Jeremy Hylton <[EMAIL PROTECTED]> wrote: > Martin, > > I'm not sure what your intent for this work is, but I'd like to create > a parallel arena branch and compare the results. I'll start work on > that tomorrow. I think this is a good thing. It will be much easier to compare implementations if we have some substantial code reflecting each technique. n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ast-objects branch created
Jeremy Hylton wrote: > I'm not sure what your intent for this work is, but I'd like to create > a parallel arena branch and compare the results. I'll start work on > that tomorrow. I certainly want the PyObject* branch to become "life" at some time; I think this is the way to go, and that an arena approach is fundamentally flawed. That said: go ahead and create a branch. This is one of the things that subversion makes convenient, and it allows people to actually judge the results when we are done. I'm personally not worried about the duplicated work: if we actually carry out the experiment of multiple alternative (or perhaps supplementing) implementations, we have much better grounds to pick the approach for the mainline. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Plea to distribute debugging lib
[Thomas Heller wrote] > Anyway, AFAIK, the activestate distribution contains Python debug dlls. [Er, a month late, but I was in flitting around Australia at the time. :)] Yes, as a separate download. ftp://ftp.activestate.com/ActivePython/etc/ ActivePython--win32-ix86-debug.zip And those should be binary compatible with the equivalent python.org installs as well. Note that the simple "install.py" script in those packages bails if the Python installation isn't ActivePython, but I could easily remove that if you think that would be useful for your users. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Subject lines of commit email
Due to popular demand, we have changed the format of the subject lines that mailer.py will send out on commit, to include the file names of the modified files (not just the directory). As the original mailer.py couldn't do that, David Goodger contributed the necessary changes. If people feel strongly that this should be reverted, we will need to take a poll, as people also feel strongly that file names in the subject line are essential. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
