Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #105950 > unrolled thread

Re-using TCL code from python over network

Started bysharad1087@gmail.com
First post2016-03-28 22:20 -0700
Last post2016-03-29 13:26 -0700
Articles 9 — 5 participants

Back to article view | Back to comp.lang.python


Contents

  Re-using TCL code from python over network sharad1087@gmail.com - 2016-03-28 22:20 -0700
    Re: Re-using TCL code from python over network Christian Gollwitzer <auriocus@gmx.de> - 2016-03-29 08:35 +0200
    Re: Re-using TCL code from python over network Karim <kliateni@gmail.com> - 2016-03-29 09:40 +0200
      Re: Re-using TCL code from python over network Christian Gollwitzer <auriocus@gmx.de> - 2016-03-29 13:18 +0200
        Re: Re-using TCL code from python over network sharad1087@gmail.com - 2016-03-29 08:02 -0700
    Re: Re-using TCL code from python over network sharad1087@gmail.com - 2016-03-29 01:37 -0700
    Re: Re-using TCL code from python over network Sharad Singla <sharad1087@gmail.com> - 2016-03-29 04:29 -0400
    Re: Re-using TCL code from python over network Karim <kliateni@gmail.com> - 2016-03-29 12:24 +0200
      Re: Re-using TCL code from python over network blacksqr@gmail.com - 2016-03-29 13:26 -0700

#105950 — Re-using TCL code from python over network

Fromsharad1087@gmail.com
Date2016-03-28 22:20 -0700
SubjectRe-using TCL code from python over network
Message-ID<172d629d-3dc8-4e47-b163-05b4f32a027c@googlegroups.com>
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

[toc] | [next] | [standalone]


#105952

FromChristian Gollwitzer <auriocus@gmx.de>
Date2016-03-29 08:35 +0200
Message-ID<ndd7h7$fhn$1@dont-email.me>
In reply to#105950
Am 29.03.16 um 07:20 schrieb sharad1087@gmail.com:
> 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).

Tcl's API (and ABI) is highly stable. I suspect that you could recompile 
most of the libraries, unless they depend on 3rd party code which is not 
portable. But of course it might be easier to call it from Python.

> 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.

You can set up a server in Tcl which will run arbitrary code from the 
network. The simplest possible server looks like this:

http://wiki.tcl.tk/15539

A more complete package (which will correctly handle scripts which span 
multiple lines etc.) is the comm package in tcllib:

https://core.tcl.tk/tcllib/doc/trunk/embedded/www/tcllib/files/modules/comm/comm.html

Beware that this is of course a security hole, you should only do it in 
a network restricted by your firewall or by employing a safe interpreter 
on the Tcl side which is sufficiently restricted.

https://www.tcl.tk/man/tcl8.4/TclCmd/interp.htm#M10

Probably the easiest way is using Tkinter from Python to send commands 
via the comm package to the remote site, i.e. tk.eval('package require 
comm') and then sending your commands by tk.eval('comm:comm send ...')

The comm protocol is very simplistic

http://docs.activestate.com/activetcl/8.4/tcllib/comm/comm_wire.html

you could also reproduce it from Python in order to reduce this jumping 
through hoops.

In the end it will always be a messy solution. As an interim solution it 
might work, but you should seriously consider recompiling the code as 64 
bit, migrating all code to Python or watch out for the libraries you 
need in modern Tcl.

	Christian

[toc] | [prev] | [next] | [standalone]


#105958

FromKarim <kliateni@gmail.com>
Date2016-03-29 09:40 +0200
Message-ID<mailman.133.1459237246.28225.python-list@python.org>
In reply to#105950

On 29/03/2016 07:20, 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

[toc] | [prev] | [next] | [standalone]


#105978

FromChristian Gollwitzer <auriocus@gmx.de>
Date2016-03-29 13:18 +0200
Message-ID<nddo39$5in$1@dont-email.me>
In reply to#105958
Am 29.03.16 um 09:40 schrieb Karim:
> 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.

tclpython embeds a Python interpreter into Tcl as a module. Therefire, 
this will only work, if Tcl and Python use the same machine language 
(i.e. 32bit or 64bit) and run on the same machine. I understood from the 
OP, that he wants to run Tcl in 32 bit mode, and connect to it from 
Python running 64 bit on a different machine. Therefore, only a true 
networked solution will work. However if he can manage to get both into 
the same process, this will be a lot easier, as outlined by your solution.

	Christian

[toc] | [prev] | [next] | [standalone]


#105989

Fromsharad1087@gmail.com
Date2016-03-29 08:02 -0700
Message-ID<1caef003-c07e-4c5b-bc43-6337f67bae84@googlegroups.com>
In reply to#105978
Thanks Christian. You are right. Our TCL is 32 bit and runs on FreeBSD. We are planning to use Python (64 bit) on CentOS.

[toc] | [prev] | [next] | [standalone]


#105962

Fromsharad1087@gmail.com
Date2016-03-29 01:37 -0700
Message-ID<6dd9aa00-1667-4d96-ae1e-953b8ddaca46@googlegroups.com>
In reply to#105950
@Christian: Thanks!
@Karim: Thanks. My requirement is to run tcl code from python. tclpython allows executing python code from tcl. "but I now I migrated all the TCL code to python one indeed" - did you re-write the TCL code in Python?

[toc] | [prev] | [next] | [standalone]


#105967

FromSharad Singla <sharad1087@gmail.com>
Date2016-03-29 04:29 -0400
Message-ID<mailman.136.1459243033.28225.python-list@python.org>
In reply to#105950
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> wrote:

>
>
> On 29/03/2016 07:20, 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
>
>
>

[toc] | [prev] | [next] | [standalone]


#105976

FromKarim <kliateni@gmail.com>
Date2016-03-29 12:24 +0200
Message-ID<mailman.145.1459247064.28225.python-list@python.org>
In reply to#105950

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

[toc] | [prev] | [next] | [standalone]


#105998

Fromblacksqr@gmail.com
Date2016-03-29 13:26 -0700
Message-ID<5948091b-2d32-4477-85a6-843a6f8cb3e7@googlegroups.com>
In reply to#105976
On Tuesday, March 29, 2016 at 5:24:37 AM UTC-5, Karim wrote:

> But it was a good experience to learn TCL (weaknesses).
> 
> Karim

I would be interested to know what you consider to be the top weaknesses of Tcl compared to Python which prompted your decision to switch.

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web