Remove builtin Tcl sub-interpreter from Python interpreter

[amykyta3]

Currently, tclpython automatically provides the tcl.eval() function in the Python namespace. This adds the ability to access a Tcl interpreter, from the Python interpreter, from the Tcl shell...

set interpreter [python::interp new]
puts [$interpreter eval {tcl.eval('clock format [clock seconds]')}]

Remove this feature for several reasons:

• I am not sure I understand the justification for why this feature would be necessary, as it is only available from a Tcl shell in the first place.
• The equivalent is already available using Python's official standard library via Tkinter. This is preferred since Python scripts would have symmetrical compatibility, and not have to rely on tcl.eval(), which is only available in an interpreter created via tclpython.

  import tkinter
  tkinter.Tcl().eval("clock format [clock seconds]")

• The tcl.eval() function is automatically imported into the python interpreter's namespace. This is a little intrusive.

[0beron]

I have used tclpython in the past in conjunction with another application written in tcl/Tk. It starts a python interpreter using tclpython, and I make use of the injected tcl module to allow the python interpreter to call back up to the parent interpreter, (mostly drawing to canvas widgets). Am I right in understanding that the tkinter.Tcl() workaround will only allow me to evaluate inside another nested TCL interpreter, that is not the original one I started the application in?

It seems similar to the situation described at https://stackoverflow.com/questions/32549839/running-tcl-code-on-an-existing-tcl-shell-from-python , with the solution being to use Tcllib and a local network connection, however the old functionality of tclpython seemed a much tidier way of achieving this?

[amykyta3]

Interesting point. You are correct that tkinter.Tcl() would not have access to the original Tcl interpreter.

When I adopted this project, I did a lot of refactoring on the original codebase and it was not immediately obvious that the old functionality was providing access back to the original interpreter. I'll look into re-enabling this feature since I see how it could be useful in some situations.

[amykyta3]

Closing since feature request is now captured in #7