Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Karim <kliateni@gmail.com>
Newsgroups: comp.lang.python
Subject: Re: Re-using TCL code from python over network
Date: Tue, 29 Mar 2016 12:24:20 +0200
Lines: 128
Message-ID: <mailman.145.1459247064.28225.python-list@python.org>
References: <172d629d-3dc8-4e47-b163-05b4f32a027c@googlegroups.com> <56FA3179.3080005@gmail.com> <CAHwJbX-u1D-y1yprCvkY=D4YaD8cLM1zbWdJNuKqoSDN77GvAg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
In-Reply-To: <CAHwJbX-u1D-y1yprCvkY=D4YaD8cLM1zbWdJNuKqoSDN77GvAg@mail.gmail.com>
Precedence: list
Xref: csiph.com comp.lang.python:105976



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@gmail.com 
> <mailto:kliateni@gmail.com>> wrote:
>
>
>
>     On 29/03/2016 07:20, sharad1087@gmail.com
>     <mailto:sharad1087@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