TCL with Perl or Python?
tcl...@gmail.com
First post here.. so no flaming please.
This post is NOT an attempt to start a flame war between Perl and
Python folks.
I've been using TclTk in my work for a few years now. Some of the
TclTk gui's are used with either csh or perl scripts to run programs
that can't be run easily from within Tcl.
I've also heard or seen a lot about how great Python is but what I
would like to know is just what are the advantages of using Python
over Perl when working with a gui created with TclTk (I use Vtcl to
initially create the gui).
At one point I had the impression that Python was a "replacement" for
TclTk.. but I see that basically Tk is used with Python.. so it really
isn't a "replacement", per se.
I don't consider myself a TclTk expert at all, but I certainly know
more TclTk and Perl than Python. I certainly don't see any reason to
spend a lot of time learning Python to develop new code.
I am sure that the Python lovers will have lots of reasons to use it
and no doubt it has a lot of advantages over Perl... but I suspect
most of those reasons will mean nothing to me.
Any comments would be appreciated.
Uwe Klein
> I've been using TclTk in my work for a few years now. Some of the
> TclTk gui's are used with either csh or perl scripts to run programs
> that can't be run easily from within Tcl.
>
> I've also heard or seen a lot about how great Python is but what I
> would like to know is just what are the advantages of using Python
> over Perl when working with a gui created with TclTk (I use Vtcl to
> initially create the gui).
Well, I think you have to take this further apart.
You have the languages:
Tcl
Python
Perl
Ruby
...
Then you have the (graphical) Toolkits:
Tk ( the c interface )
Gtk
Qt
Fltk
....
Then you have (scripting) language Bindings for the Toolkits.
Tk ( as in package require Tk )
Ttk ( TileTk )
Tkinter
PyTk ??
RubyTk
... lots of others
Then you
can use Tk via Tcl as an embedded interpreter in another language
like forex tclperl
http://jfontain.free.fr/tclperl.htm
and similar .
I had thought about doing a language sex/rishathra table once, but .. ;-)
uwe
schlenk
> would like to know is just what are the advantages of using Python
> over Perl when working with a gui created with TclTk (I use Vtcl to
> initially create the gui).
When working with a Tcl/Tk created GUI there is no real benefit in
using Python or Perl.
There are some benefits to both Perl and Python, mostly if you have a
lot of people knowing Perl or Python already or if you need to use
some module only available for those languages. But otherwise they are
pretty similar.
Python has some nice spots, some language constructs are pretty nice,
but a lot of warts too. If you need x-platform stuff like Windows +
Unix you will find a lot of tiny warts on Python, things that just
work in Tcl and have you add if sys.platform = 'win32' all over your
code in Python. Perl is similar, they work on a lower level of
abstraction usually (but offer more control about those lower levels
as a benefit).
When using Perl or Python you basically loose the x-platform
convenience that are Starkits/Starpacks, so no single file deployments
for you anymore. Python has various similar solutions but none is
really cross platform or as convenient.
When you have a Tk GUI you also loose some ease of use, as the Python
and Perl Tk bindings (tkinter,Tcl::Tk) are not as nice for working
with Tk as the native Tcl bindings. If your not locked into Tk you can
explore some other GUI toolkits with those other languages, which
might be an interesting option if you target Apple systems and want
native Cocoa GUIs but forget X-Platform in that case.
I have to work with Python in my day job since two years, and have
done a lot of Tcl before and must say, Python feels like programming
with one hand bound on your back. Its more of a bondage and discipline
language than Tcl, there is a specific way to do things and you should
do it that way, or your code gets horrible complex, brittle and ugly.
One thing i think Tcl lacks is a modern, portable web framework (yes,
there is OpenACS, but thats not really portable as it is bound to
AOLserver), all the current options don't really play in the same
league as Ruby on Rails, Pythons Django and similar offerings. But if
you don't do web UIs, you couldn't care less.
A similar issue comes up with ORM layers, Python has various, e.g. the
nice SQLAlchemy system, but one reason Tcl might lack widespread
adoption of an ORM is that Tcl simply is not a pervasive OO language
like Python, so people are pretty okay with writing procedural code
sometimes. Tcl 8.6. with the new TDBC and the OO system might change
that in the near future though.
Where both Python and Perl suck is multi-process control or network
servers. Python without extra libs offers barely more than what the
BSD socket API in C would give you, which is pretty low level and hard
to work with. Even C++ with Boost libs is far better than that.
Because of that all the standard protocols in Python either use
Threads or are blocking by default and you need a huge beast like
Twisted or coroutine libs like eventlets to get a decent network
server built in Python. Don't let yourself distract by the toy
examples you see for Python usually, ask for the non blocking version
to see the uglyness.
Encodings are a mess too, at least in Python 2.x, Python 3.x basically
adopted the Tcl model (which Tcl copied from Java) where all strings
are Unicode and you convert on I/O. One plus for Python 3.x is that it
supports more than the Basic Multilingual Plane of Unicode, a thing
Tcl still lacks due to manpower implementing it.
If you work with time and date you will hate Python compared to Tcl
8.5 and newer. Tcl's clock command beats Pythons offerings hands down
in everything but speed. You don't have any reasonable timezone or
locale support for datetime in Python, your basically working with a
thin, non portable wrapper around C standard strftime() and
gettimeofday().
Threading is another issue with Python. It has a simple Threading API
in its stdlib, but for anything but I/O bound programs its totally
worthless due to a global lock around all data structures (in CPython
at least, the .NET and Java implementations don't have this issue),
Tcls message passing based threading is vastly better if you don't
have huge shared datastructures (that would be better in a database in
many cases anyway). In recent Version Python added the multiprocessing
module which offers some options to use processes instead of threads,
but its not really superior to e.g. Tcl with fileevent/open and
something like tequila or tcllib comm to communicate.
XML processing. Python offers xml in its stdlib via elementtree, but
if you know tdom for Tcl you will hate it. Its crap, does not even do
basic syntax checking (you can build cycles of nodes ;-)) and is a
memory hog. No xslt or xpath support either. There are external
modules that are better though.
Hashlib/Crytpo. The stdlib of Python does offer less options than
Tcllib, no crypto at all (okay, ssl for sockets/streams, but thats
it). But there are good extensions that add all you need.
File system utitilies. The Python stdlib offers quite some, but those
are so-so in usability. Newer versions are pretty okay, older ones are
near to totally worthless on Windows. Tcllibs fileutil, multiop and
related modules are pretty much nicer. No VFS support for python
either so no option for cute tricks there. They hacked something like
starkits with Python eggs (zip files), but those are not much more
than loading code and stuff from a zip file.
Security/Multiple Interpreters. Python offers a similar solution to
Safe Interpreters, its just deprecated and know to not work. Basically
if you try to embed Python in any app you have one interpreter and
just one interpreter. No way out. No chance to do one interpreter per
user models without big surgery.
The module system. Python offers modules, quite similar to Tcl
modules. They don't have stubs so you need to recompile all your C
extensions if you upgrade your Python core. Python couples namespaces
to modules, so if you have a module you have a namespace too, unlike
Tcl where those are distinct dimensions of splitting your code. Python
modules by default have no versioning, so you have a hard time to have
two versions of a Python module around unless you add that info to the
filename (like Tcl modules, unlike tcl packages).
So whats left over? Some low level stuff like mmap and ctypes (which
are pretty nice to have), decimal (for fixed precision math), a built
in debugger (pdb), a little more execution speed in benchmarks.
Value semantics. Python has both mutable and unmutable values by
default, very often using mutable values/references, with all the
gotchas that brings. One favorite gotcha are mutable default
parameters to functions. Makes it easier to build complex data
structures in Python, but makes it harder to debug sometimes.
Traces. Python does not offer functions like Tcls trace, but it allows
one to overwrite accessors for objects to achieve similar effects with
more code.
Documentation. Pythons docs look nicer and are a bit better organized.
Content varies a bit, some stuff simply lacks or is hard to find
(object model, super() and similar topics).
The main reason to use Python would be to use some lib not available
for Tcl directly like NumPy or similar things.
Michael
Cameron Laird
Wow.
Is flaming something you prefer on a second post?
Briefly, if your configuration is working for you, there's
no compelling reason to switch from Perl to Python--that
*was* your question, correct?
tcl...@gmail.com
Wow..
Thanks to both of you for all the info... especially Michael ... I
can't believe you took the time to write so much.
Thank you very much.
I guess if what I am currently doing works... using Python isn't going
to make things any easier and will probably make it harder.
Thanks again.
Cameron Laird
Your description intrigues me. If I'm working with Tcl/Tk,
I think of Perl or csh as adding little incremental capabilities,
OR if I'm working with Perl, I'm more inclined to use Perl/Tk or
Tcl::Tk than Tcl/Tk or csh or ... What exactly do Perl, csh, and
Tcl do for you?
Georgios Petasis
I want to add a small web gui to an existing app, and still I haven't
found a solution...
George
O/H schlenk έγραψε:
Uwe Klein
> What exactly do Perl, csh, and
> Tcl do for you?
Hmmm, that exactly seems to have been the question?
uwe
tcl...@gmail.com
> Now that you mentioned web guis, tcl is far behind on this :-(
>
> I want to add a small web gui to an existing app, and still I haven't
> found a solution...
>
> George
>
Cameron Laird
schlenk <sch...@uni-oldenburg.de> wrote:
.
[marvelous write-up]
.
.
>Security/Multiple Interpreters. Python offers a similar solution to
>Safe Interpreters, its just deprecated and know to not work. Basically
>if you try to embed Python in any app you have one interpreter and
>just one interpreter. No way out. No chance to do one interpreter per
>user models without big surgery.
>
>The module system. Python offers modules, quite similar to Tcl
>modules. They don't have stubs so you need to recompile all your C
>extensions if you upgrade your Python core. Python couples namespaces
>to modules, so if you have a module you have a namespace too, unlike
>Tcl where those are distinct dimensions of splitting your code. Python
>modules by default have no versioning, so you have a hard time to have
>two versions of a Python module around unless you add that info to the
>filename (like Tcl modules, unlike tcl packages).
>
>So whats left over? Some low level stuff like mmap and ctypes (which
>are pretty nice to have), decimal (for fixed precision math), a built
>in debugger (pdb), a little more execution speed in benchmarks.
.
.
Quibbles: security in Python is worse than you describe,
in that I've seen no survivors of the brain surgery
believed to be required for safe interpretation.
Python lacks stubs. PYTHON LACKS STUBS! Until you've
lived with(out) it, you have no idea how important this
is. Some Python extensions essentially never migrate from
their original release.
Please do not think that Python is a little faster than
Tcl. It's a little faster on some benchmarks, a little
slower on others, MUCH slower on a few. I know of no
significant cases where Tcl is much slower. To first
order, they're equal.
Cameron Laird
<tcl...@gmail.com> wrote:
.
.
.
>Thanks for taking the time to write all of that and confirm what I
>suspected... if what I am currently doing works, there is really no
>reason to switch to Python just for the sake of switching.
>
>Thank you very much.
There is indeed no benefit to a switch to Python
in the situation you have described.
Alan has written me privately. I'm going to take
the luxury and liberty of responding to a few items
here in public, in the hope that others can answer
better than I.
Alan wrote, "... obviously I'm not a programmer."
I have no idea how to parse that.
He explains, "... one gui basically is used just
to build the command line input that then gets sent
to a csh script that 'blends' the models together
and produces output ..." While this certainly
doesn't sound like something I'd create, if it works
for Alan and his employer, I see no need to change.
Alan tells, "... Perl's sort command does this
nicely. . . ." Tcl's [lsort] is equally capable--but
then, so is sort(1). As tempting as it might be to
show off elimination of an entire Perl process at
one whack, my professional opinion is that Alan and
his team are best off keeping what works for them.
Linux workstations host their processes. Their
production output is pure upper-case (!) text.
My guess is that Alan and his team have better
things to do with their talents than to re-implement
their systems in yet another language. While I remain
unsure what his original question was, I hope that
answer is in its neighborhood.
Gerry Snyder
> Now that you mentioned web guis, tcl is far behind on this :-(
>
> I want to add a small web gui to an existing app, and still I haven't
> found a solution...
Not sure exactly what you mean, but I assume you've looked at aejaks?
Gerry
George Petasis
Exactly what I mean. Yes I have checked aejacks, but it depends on java,
and is not easy at all to integrate in an application.
I think it is not possible to co-operate with an active tcl
distribution, isn't it so?
George
sleb...@gmail.com
wrote:
My best guess is that they are all victims of their own success. When
all are relatively easy to learn (especially if you just need to know
enough to get the job done) and all make good glue languages, then in
the situation where all you need is simply to get the job done they
will inevitably glue to each other.
tcl...@gmail.com
> In article <0fc8ab2d-c22f-4aad-a7df-48930847e...@t11g2000yqg.googlegroups.com>, <tcl...@gmail.com> wrote:
in the situation you have described.
> Alan tells, "... Perl's sort command does this
> nicely. . . ." Tcl's [lsort] is equally capable--but
> then, so is sort(1). As tempting as it might be to
> show off elimination of an entire Perl process at
> one whack,
I would certainly like to see how to accomplish the following in tcl:
@sorted=(sort {(@{$a}[6] cmp @{$b}[6]) || (@{$a}[1] cmp @{$b}[1]) || (@
{$b}[3] <=> @{$a}[3]) || (@{$a}[2] cmp @{$b}[2])} @all) ;
Aric Bills
I'm not much of a Perl programmer, but if the above code says to do
this:
sort on element 6 using string comparison,
then on element 1 using string comparison,
then on element 3 using numerical comparison,
then on element 2 using string comparison
then a Tcl equivalent might be:
proc sortcmd {a b} {
return [expr {
[string compare [lindex $a 6] [lindex $b 6]] ||
[string compare [lindex $a 1] [lindex $b 1]] ||
[lindex $a 3] - [lindex $b 3] ||
[string compare [lindex $a 2] [lindex $b 2]]}]
}
set sorted [lsort -command sortcmd $all]
Andreas Leitgeb
>> I would certainly like to see how to accomplish the following in tcl:
>> @sorted=(sort {(@{$a}[6] cmp @{$b}[6]) || (@{$a}[1] cmp @{$b}[1]) || (@
>> {$b}[3] <=> @{$a}[3]) || (@{$a}[2] cmp @{$b}[2])} @all) ;
> I'm not much of a Perl programmer, but if the above code says to do
> this:
> sort on element 6 using string comparison,
> then on element 1 using string comparison,
> then on element 3 using numerical comparison,
> then on element 2 using string comparison
> then a Tcl equivalent might be:
> proc sortcmd {a b} {
That's slow (from what I gathered from previous posts here).
It may be worth a try to use the stableness of tcl's sort:
sort multiple times, starting with last (least important)
criterion up to the first criterion:
set all [lsort -index 2 -- $all]
set all [lsort -integer -index 3 -- $all] ;# or -real
set all [lsort -index 1 -- $all]
set all [lsort -index 6 -- $all]
There may of course be other situations, where a sortcmd is
inevitable.
> [string compare [lindex $a 6] [lindex $b 6]] ||
> [string compare [lindex $a 1] [lindex $b 1]] ||
> [lindex $a 3] - [lindex $b 3] ||
> [string compare [lindex $a 2] [lindex $b 2]]}]
This wouldn't work, anyway, because in tcl "-1 || ..." evaluates
to "1", not to "-1" (as perl's || would).
Andreas Leitgeb
> It may be worth a try to use the stableness of tcl's sort:
> sort multiple times, starting with last (least important)
> criterion up to the first criterion:
>
> set all [lsort -index 2 -- $all]
> set all [lsort -integer -index 3 -- $all] ;# or -real
> set all [lsort -index 1 -- $all]
> set all [lsort -index 6 -- $all]
And speed can perhaps(*) again be improved by using one of
those tricks along with the K-combinator, as described on wiki:
http://wiki.tcl.tk/1923 (search for "get-and-unset")
IIRC, by replacing each of the four "$all"'s by: "$all[unset all]"
the effect can be had without defining a "K" procedure.
Due to a specific optimisation some time ago "$all[unset all]"
will *not* do a detour to string-representation.
*: But then again, I don't know, if lsort is among those commands
that benefit from unshared values, in the first place.
Alexandre Ferrieux
wrote:
>
> *: But then again, I don't know, if lsort is among those commands
> that benefit from unshared values, in the first place.
No it isn't :-}
Indeed, as commented in the code, we start by doing a "cheap copy" of
the initial list (ie just creating a second Tcl_Obj reference above
the same internal List structure), to avoid nasty bug when a -command
callback makes the original object shimmer. The net effect is that the
List's refcount will be >=2, precluding any in-place operation
(independently from the fact that MergeSort is not designed for in-
place).
In all this, the true killer is the overhead of a scripted callback.
Perl beats Tcl on this specific task because the notion of
lexicographic composition of fields is a C built-in. Of course we
could do the same, given a sufficient incentive...
-Alex
Aric Bills
Donal K. Fellows
> I would certainly like to see how to accomplish the following in tcl:
>
> @sorted=(sort {(@{$a}[6] cmp @{$b}[6]) || (@{$a}[1] cmp @{$b}[1]) || (@
> {$b}[3] <=> @{$a}[3]) || (@{$a}[2] cmp @{$b}[2])} @all) ;
If I want to make my eyes water, I prefer an onion or a sad piece of
music. When code does it, I think it's a bad sign. :-)
I have a feeling that the solution will involve [lsort -command],
[lindex] or [lassign], [string compare] and a helper procedure or lambda
application. It will also be far more clear about just WTF is going on.
(What does @{$a} do in this context? I can think of two interpretations,
but which is correct determines whether we're talking [upvar] or lists
of lists...)
Donal.
David N. Welton
<donal.k.fell...@manchester.ac.uk> wrote:
> tcl...@gmail.com wrote:
> > I would certainly like to see how to accomplish the following in tcl:
>
> > @sorted=(sort {(@{$a}[6] cmp @{$b}[6]) || (@{$a}[1] cmp @{$b}[1]) || (@
> > {$b}[3] <=> @{$a}[3]) || (@{$a}[2] cmp @{$b}[2])} @all) ;
>
> If I want to make my eyes water, I prefer an onion or a sad piece of
> music. When code does it, I think it's a bad sign. :-)
I think misconfiguring the tty options to [open] and spitting out the
results of a conversation with a modem might be one way of
accomplishing the above...
Friedrich
> Now that you mentioned web guis, tcl is far behind on this :-(
Not true, look vor OpenACS. There's less which can be compared to it.
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Donal K. Fellows
wrote:
> In all this, the true killer is the overhead of a scripted callback.
> Perl beats Tcl on this specific task because the notion of
> lexicographic composition of fields is a C built-in. Of course we
> could do the same, given a sufficient incentive...
They have a different internal representation of the code to us which
has some advantages (as well as other disadvantages elsewhere) though
at the moment we use about as efficient a dispatch mechanism as we
can. The cost of using -command used to be much higher (but if you can
use the built in comparators, that's much faster even so).
Donal.
Donal K. Fellows
wrote:
> [Using lsort -command is] slow (from what I gathered from
> previous posts here).
>
> It may be worth a try to use the stableness of tcl's sort:
> sort multiple times, starting with last (least important)
> criterion up to the first criterion:
It's important to actually try the two alternatives at this point. For
small lists, I'd expect repeatedly sorting to win. For large lists,
sorting once might be better. Experiment, don't speculate.
Donal.
Alexandre Ferrieux
wrote:
If I may speculate still :)
The -command overhead is multiplied by O(N*log(N)).
The repeated sorting is times O(N).
So I'd predict Andreas' trick to win for large lists.
Of course I have no idea of how large they should be. MAXINT**13 would
be nasty.
-Alex