Parsing files in python

Terry Reedy tjreedy at
Mon Dec 24 02:46:49 CET 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 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

# 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 file you provide.

Terry Jan Reedy

More information about the Python-list mailing list