tcl list to python list?

Paul McGuire ptmcg at austin.rr._bogus_.com
Sun Sep 17 19:52:00 EDT 2006


"Cameron Laird" <claird at lairds.us> wrote in message 
news:3k70u3-3d8.ln1 at lairds.us...
> In article <CE4Pg.4266$vD2.1873 at tornado.texas.rr.com>,
> Paul McGuire <ptmcg at austin.rr._bogus_.com> wrote:
>
<yet another post showing a pyparsing stab at a parsing problem, this time 
parsing Tcl lists>
>
> Noooooooooooooooooo!
>
> I'll be more precise:  pyparsing is quite wonderful, and I'm
> all in favor of clever demonstrations of its capabilities.  I
> don't think this is one, though; in fact, although I haven't
> yet paid enough attention to the original question to provide
> an example, I'm reasonably certain that the code offered above
> mishandles at least some data (Tcl syntax is different from
> what outsiders expect).
>
> Paddy's advice elsewhere in this thread is almost entirely
> correct.  Anyone who has imported Tkinter has all of Tcl avail-
> able immediately, so much the easiest, most reliable, most
> maintainable, and most lucid solution is simply to iterate in
> Tcl over the list, and construct thus the corresponding Python
> list.
>
> I'm willing to write either a correct implementation, or a
> counterexample with problematic data, if these sufficiently
> interest readers.  It'll be a day or two before I can make the
> time to be careful, though.

Cameron -

Er?  Thanks for the nice comments re: pyparsing, sometimes I feel a little 
self-conscious always posting these pyparsing snippets.  So I'm glad you 
clarified your intent with your "I'll be more precise" paragraph.  But I'm 
not sure I see the reason for an 18-O "No!"

"Outsider"?  I'm no stranger to Tcl (although I *am* a bit rusty).  In the 
90's I worked for several years with a script-based process control system 
for semiconductor manufacturing, in which we used Tcl for customer-defined 
control logic.  Tcl led me to appreciate the value of a scripting language, 
despite its clunky assignment syntax ("set x 1"), and "$"-happiness.  When I 
looked into Python a few years later, I remember thinking "Man, I wish we 
could have used Python instead."

I took a look at how accessible Tcl is using Tkinter.  It looks to me like 
one would need to:
- write a Tcl proc to recursively traverse a list, returning a stringified 
list in Python-like syntax (enclosing non-list items in ''s, separating with 
commas, nesting sublists with []'s, etc.)
- construct a string passing the OP's Tcl list string "sql  commands ex: 
..." to this method
- invoke Tkinter.Tk().eval on this string to perform the Tcl traversal
- invoke Python's eval function on the returned string to get an actual 
list.

Did I get that right?  Or is there another, simpler back door into Tcl from 
Tkinter?

I'll confess, I wrote my sample code based on the sample text posted by the 
OP, without much extra syntax (such as negative integers or floating-point 
values).  So here is a version with a bit broader coverage:
======================
tcl = """sql commands ex:
 { begin { select * from foo
                where baz='whatever'}
  {select * from $gooble } { } end
  { insert into bar values('Tom', 25) } }"""

from pyparsing import *

tcllist = Forward()
element = quotedString | Combine(Optional("$") + Word(alphas,alphanums+"_")) 
| \
          Combine(Optional(oneOf(list("+-")))+ Word(nums) + "." + 
Optional(Word(nums)) ) | Word(nums+"+-",nums) | \
          oneOf( list(r"(),.+=`~!@#$%^&*-|\?/><;:") ) | Group( '{' + tcllist 
+ '}' )
tcllist << ZeroOrMore( element )

import pprint
pprint.pprint( tcllist.parseString(tcl).asList() )
======================

This should handle empty lists, signed integers and reals, and variables 
with leading '$' signs.

Before putting too much effort into problematic counter-example data, it 
might be a good idea to check with the OP, to see what types of values are 
likely to come up in practice.  Given that c.l.py posting is only a 
spare-time activity (probably so for you, too), I wouldn't want to waste 
time on the be-all-and-end-all Tcl list parser that handles cases the OP 
wont run into.

-- Paul 





More information about the Python-list mailing list