With the document parse coded and tested, I turned my attention to coding the function that will actually invoke a Translator when one is selected from the menu. I spent a couple of hours tidying and rearranging the code of translators.py and coding the framework of the function. My approach to this is to write a comment prolog saying what I'm going to do, and revising that over and over as I realize why I can't do that, at least not in that sequence, so I'm actually going to do this, etc. etc.
The first steps are known and I could code them: find if the Translator had a user-options dialog and presenting it; parsing the document. But then: time to start actually calling the Translator. This brought me face-on to the question of what exactly is the interface to the Translator. I had a detailed sketch of a design from weeks ago but knew more now. So I changed modes and spent about 3 intense hours rewriting the API spec. I made several on-the-fly decisions that simplified it from before. Really, any competent Python programmer—who also understands the full range of things that can occur in a DP document—and who also understands in detail the syntax of the target document format—should have no difficulty writing a Translator.
When I put it that way, it suggests a Venn diagram of three circles for which the little triangle where all three overlap might be rather small. But for the select group of people in that happy spot—no problem.
No comments:
Post a Comment