Special-purpose extension of Python -- new kinds of objects
robert_dodier at yahoo.com
Mon Dec 29 17:59:09 CET 2003
Jeff Epler <jepler at unpythonic.net> wrote:
> In your case, you could re-cast the "decision network" in terms of class
> definitions, and get pretty similar behavior if those classes have the
> right behavior in metaclasses: [...]
I'd rather not try to shoehorn the decision model description into
a description in terms of Python classes. I'd like to try to keep
the description as natural as possible.
> If you're very fond of your syntax, then consider using strings
> as the easiest way. Docstring abuse has been seen before, and
> would look something like this: [...]
I've implemented similar systems by loading files in one format
or another -- XML was the latest attempt; I won't be trying that
again -- and, to explore just how far the integration with Python
can be taken, I'm wondering what it would take to merge the model
description with Python. I'd like to have Python in the model
(to return probability & utility values) as well as model in the
> There is a languishing PEP about exposing the Python parser generator to
> Python code, so that you could write your own grammar with the same
> level of power as Python's grammar. There are lots of other package,
> such as yapps and spark which are also suitable for writing parsers.
Yes, I've seen the PEP in question (PEP 269), I'll take a closer
look. I'll look at yapps and spark too.
> Once you have a parser and use external files, it's possible to extend
> Python's import system to load files of your type automatically with
> the import statement. This is an advanced topic, though.
Well, that's not out of the question. Can you give a reference
to a starting point for hacking on the import system?
Thanks for your interest. I appreciate your help.
``Supreme executive power derives from a mandate from the masses,
not from some farcical aquatic ceremony.'' -- Dennis (MP&THG)
More information about the Python-list