Re-using TCL code from python over network
Karim
kliateni at gmail.com
Tue Mar 29 06:24:20 EDT 2016
On 29/03/2016 10:29, Sharad Singla wrote:
>
> Thanks. This is more of invoking python code from TCL. I am looking
> for the other way round.
>
> Curious, did you rewrite all your TCL code in python?
>
> Regards
> Sharad
>
> On Mar 29, 2016 1:10 PM, "Karim" <kliateni at gmail.com
> <mailto:kliateni at gmail.com>> wrote:
>
>
>
> On 29/03/2016 07:20, sharad1087 at gmail.com
> <mailto:sharad1087 at gmail.com> wrote:
>
> Hi
>
> We've a test automation framework written in TCL (including
> the automated test cases). We are evaluating shifting to
> Python and have a test framework in Python (including the
> automated test cases). Python provides a lot more 3rd party
> libraries that we'd like to make use of.
>
> We use a pretty old version of TCL (8.4.5, 32 bit). It's on
> FreeBSD and we've compiled it in-house. Compiling it to 64 bit
> or moving to a newer version is a massive task (since we've a
> lot of libraries - written in C and compiled as well as pure tcl).
>
> Also, we are evaluating having this Python infrastructure on
> Linux (CentOS).
>
> I've explored Python's Tkinter but it won't suit our case as
> it points to system installed TCL. I've also explored Python's
> subprocess (launch an interactive TCL shell remotely) and
> pexpect but none of them worked well for me to allow me to use
> TCL code interactively from Python.
>
> I'd like to gather any ideas/experience around this. If anyone
> has tried a similar stuff before and can share his/her
> experience, I'd appreciate it.
>
> Regards
> Sharad
>
>
> You can find below a partial example where I launch a python
> process from a tcl program to get data from python
> which reads a database. You just have to get and compile tclpython
> (google is your best friend) which is a C interface
> bridging python and tcl and allow to launch at most 5 python
> interpreter processes if I remember correctly. I used it during 4
> years but I now I migrated all the TCL code to python one indeed I
> don't need it anymore. But it is useful to do the transition.
>
> #!/usr/bin/env tclsh8.4
>
> lappend auto_path $env(TCLPYTHON_PKG_PATH)
> package require tclpython 4.1
>
> namespace eval ops {
> namespace export initPython
> namespace export exitPython
> ...
> namespace export getDeviceDescription
>
> ....
> }
>
> proc ops::initPython {} {
> # ----------------------------
> # @goal: Create the interpreter process and import python needed
> modules.
> # @arg: <none>
> # @return: <none>
> # ----------------------------
> variable interpreter
> set interpreter [python::interp new]
> $interpreter exec {from ops.tcl.pythontcl import
> to_string, to_list, to_dict, to_bool}
> ....
> $interpreter exec "opsdb = None"
> $interpreter exec "input_structure = dict()"
> }
>
> proc ops::exitPython {} {
> # ----------------------------
> # @goal: Close the interpreter process.
> # @arg: <none>
> # @return: <none>
> # ----------------------------
> variable interpreter
> python::interp delete $interpreter
> }
>
> proc ops::getDeviceDescription { libName deviceName } {
> # ----------------------------
> # @goal: get
> # @arg: <none>
> # @return:
> # ----------------------------
> variable interpreter
> $interpreter exec "d_s = to_string(getDeviceDescription(opsdb,
> '$libName', '$deviceName'))"
>
> eval "set value [$interpreter eval {d_s}]"
> return $value
> }
>
> Karim
>
>
Yes, part by part. In fact it was faster than expected thanks to python
syntax.
TCL coding is heavier than python equivalent. I say that by experience.
My project involved 2 developers one pro TCL and myself pro Python.
We found the best deal for both. Now I am alone. This is the reason
everything is now python.
But it was a good experience to learn TCL (weaknesses).
Karim
More information about the Python-list
mailing list