Parsing files in python
Terry Reedy
tjreedy at udel.edu
Sun Dec 23 20:46:49 EST 2012
On 12/23/2012 12:19 PM, Kene Meniru wrote:
> Hello: I am writing a program that is made up of a collection of
> POV-Ray macros. POV-Ray is available at povray.org. It is a
> ray-tracing program that reads a scene description language (SDL) to
> create photo-realistic images. At this time my program (for modeling
> building information) is so huge that I am finding it difficult
> managing the macros and I am not even near completion.
>
> I am hoping to move this program to python and am wondering the best
> way to approach this.
>
> I would like to model my program after LaTeX. Basically the user
> writes a text file using certain key words and numbers and my python
> program reads this file, calls the classes that will then work
> together to calculate the information that is needed to create an
> accurate model. The result of this calculation will be an output to
> another text file in the appropriate format such as POV-Ray SDL,
> OpenSCAD script, etc. This file output can then be rendered by the
> corresponding program to produce the actual 3D model. The macros I
> have now currently does this but like I said it is getting tedious
> and most importantly the fun factor is losing its strength for me.
>
> I have been advised to check out python-ply and I have come across
> others. I have not really tried any yet and before I dive into any
> one of them I was wondering what else I should know. The following is
> a sample of what the text file that will be processed by this
> proposed system will contain. I appreciate any pointers and
> suggestions.
Mine is "Don't do that." Seriously. What I understand is that you are
proposing to design and write a parser for yet another Domain Specific
Language -- that will require knowledge to use that is useless outside
the specific domain. I expect that is will come to duplicate the basic
facilities of existing languages. Users will want to be able to
calculate, make conditional calculations and constructions, iterate*,
and define functions (subroutines, macros). Why bother to reinvent all
that? It often becomes a mess. (Or you will offer or people will want to
mix Python with the dsl. That also can become a mess.)
Instead, write a pypovray package incorporating the POV macros, that can
be imported into a python program. Write a tutorial for the specific
parts of Python that users will need.
For instances, someone wants to place duplicate or parameterized models
on a rectangular grid, along an arc, or even at random locations.
> ------------possible user file content for parsing ------------ // in
> the following the python interface program reads //+ the contents of
> the file "other.file" as if its content //+ were located at this
> point.
# this is a python comment. trivial difference from //
> include other.file
import other.file # with Python's variations
# or
exec(open('other.file')) # but it is nearly always better to
# keep the separate namespace. What if a name in other.file
# is the same as used below?
import pypovray as ppr
> //In the following the python interface makes "snap_size" a //+
> global parameter
> declare snap_size = 10
snap_size = 10 # the extra word is just noise
> // In the following "buildingLevel" is a class that is //+ called
> and passed the parameters in parenthesis. buildingLevel("FirstLevel",
> 3000)
>
> // In the following "snapOffset" is a class that is //+ called and
> passed the parameters in parenthesis.
> snapOffset("Closet-S1_r1", "Closet-S2_r3", <0,0,0>)
Already legal Python
# at the end of the file
ppr.run(args)
# Reads globals(), which python has nicely created for you, to create
the master scene description and output whatever is needed for povray.
It could be part of a template.py file you provide.
--
Terry Jan Reedy
More information about the Python-list
mailing list