Bolting a Bison/Flex parser into Python

[Clint Olsen]

Dave:

The data and usage model I was considering was that of reading in
connectivity netlists for schematics.  The datasets could possibly become
large, so having a strict Python parser would defeat the "mobility" of
using the parser with other applications (as you mentioned).

But, your assumptions are correct.  I'm interested in being able to write
Python code which access the data sets: dictionaries of designs, nets,
cells, pins, and other things.  The dictionaries in conjunction would
represent an entire schematic which is a directed graph: Given a cell (by
name) find out all the pins connected to the cell.  From that, get all the
nets; find all the cell pins connected to those nets... ad nauseum.

The most popular C interface I've read about is SWIG, but it is not really
want I want to do.  If I have to write interface functions and obtain each
piece of data one at a time using function calls, it sort of defeats the
fluidity of the native application of Python or Perl.  You want to be able
to use pre-created lists, dictionaries, tuples (whatever) to maximally
utilize the language.

You want to be able to write code (excuse the Perl):

@pins = $cell{"AND024"}{"pins"};

which is natural to the language, rather than:

$pin = get_next_pin("ANND024", $prev_pin);

>From this I can build a small arsenal of routines that would facilitate a
design query suite.

Thanks,

-Clint

On 12 May 2000 09:58:41 +1000, Dave Cole <djc at itga.com.au> wrote:
>
>Not sure if it is a reasonable way to go because you have not provided
>enough information to make that decision.
>
>I imagine that it would not be too hard to achieve what you want to do.
>One of the big reasons for using bison is that the parser is going to be
>pretty fast.  Certainly much faster than the same thing in Python.
>
>You did not mention the structure, volume, and typical usage patterns on
>your data, so it is a bit hard to make a good recommendation.  If you are
>dealing with a large amount of data of which applications typically access
>less than 10%, then you could benefit from a technique I have used here to
>speed Python programs by an order of magnitude.
>
>By loading all of the parse tree into native C structures, you retain
>compatibility with the non Python applications.  You could then wrap those
>native C structures with Python proxies on demand.  If the Python program
>does not access an attribute, then do not create it.  References to child
>parse tree nodes are handled in exactly the same way.  When a reference to
>a child node is used, create the proxy for the child and cache the
>reference in the proxy for the parent node.
>
>If you need any more explanation, I would be more than happy to help you
>out.