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" <kliat...@gmail.com
<mailto:kliat...@gmail.com>> wrote:
On 29/03/2016 07:20, sharad1...@gmail.com
<mailto:sharad1...@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
--
https://mail.python.org/mailman/listinfo/python-list
