What is the most pythonic way to build up large strings?

Eric S. Johansson esj at harvee.org
Sat Feb 8 09:42:31 EST 2014


On 2/8/2014 3:35 AM, Rustom Mody wrote:
> On Saturday, February 8, 2014 1:11:53 PM UTC+5:30, cstru... at gmail.com wrote:
>> I am writing a couple of class methods to build up several lines of html.  Some of the lines are conditional and most need variables inserted in them.  Searching the web has given me a few ideas.  Each has its pro's and cons.
> For creating html the method of choice is a template engine -- cheetah, mako
> and a dozen others
>
> You can of course roll your own (poor mans version) template engine
> For that look up
> 1. triple quoted strings
> 2. format operator
as so happens, I'm traveling down a similar path myself. My goal is to 
use it to generate code for disabled, speech recognition using 
programmers (like myself). I believe my best route is using a modified 
version of string.Template but I wonder if my biases keep me from seeing 
a good alternative. I believe the following characteristics are essential:

Easy to speak
output generated with the right indentation
recursive expansion
can list substitution names


Here's an example of use. The current model for visual output is a split 
screen simulated as text between two long lines of 
--------------------------------:

Saying: add method

----------------------- in the GUI/editor 
-----------------------------------------
method_name??undefined
-------------------------
def method_name():
-----------------------------------------------------------------------------------------

Saying: add three arguments
----------------------- in the GUI/editor 
-----------------------------------------
method_name??undefined
argument_1??undefined
argument_2??undefined
argument_3??undefined
-------------------------
def method_name(argument_1, argument_2, argument_3):
-----------------------------------------------------------------------------------------

Saying: fix undefined
----------------------- in the GUI/editor 
-----------------------------------------
method_name??^
argument_1??undefined
argument_2??undefined
argument_3??undefined
-------------------------
def method_name(argument_1, argument_2, argument_3):
-----------------------------------------------------------------------------------------

Saying some method name
----------------------- in the GUI/editor 
-----------------------------------------
method_name??some method name
argument_1??undefined
argument_2??undefined
argument_3??undefined
-------------------------
def some method name(argument_1, argument_2, argument_3):
-----------------------------------------------------------------------------------------

You repeat the process saying "fix undefined"until all of the 
substitution names were filled in and the expanded template in the lower 
window was correct. The conversion from string names such as "some 
method argument" to codenames (SmMnm) happens in a different part of the 
process.

The problem am working on now is if I change something in the list of 
substitution names (upper window) how does that affect the code 
generated and shown in the lower window? The vast majority of the time, 
deleting a substitution name resets it to undefined. But deleting 
argument is special. At the moment, I'm going with explicit alteration 
of an argument list rather than inferring the argument list from the 
arguments in the substitution name window.

I'm reasonably sure that templates, some sort, are the way to go for 
reducing vocal load. What I'm still wrestling with is the kind of 
overhead I impose on the programmer and that, in turn, defines the kind 
of templates I need for programming by speech.

Solving this problem has made me curse one feature of Python which is 
it's type system. Something, more static, would make things much easier 
because the type information could be used to predict what will be said 
next thereby reducing the number of hacks, such as templates, necessary 
to write code. However, given that one can write Python reasonably well 
using ordinary speech recognition, I can almost live with its type 
system. :-) but, if somebody knows a way to make an empirical 
determination of type, I wouldn't turn away the help



More information about the Python-list mailing list