A Tcl/Tk programmer learns Python--any advice?

[Kevin Walzer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm a Tcl/Tk developer who has been dabbling with Python for some time,
but had not seen a compelling reason to really learn the language.
Programming in Tkinter seemed redundant to me since I already have
direct access to that toolkit via Tcl, and the other Python GUI toolkits
I tried--PyQt and wxPython--were frustrating with their learning curve.

Well, I have finally found a good reason to learn Python in more depth:
the language already directly supports things that I want to do in my
next project (specifically the Carbon modules in Mac OS X), whereas Tcl
would require a lot of extending in C before I could get started. I've
decided that it's probably less work to learn the Python way of doing
things, and if I stick with Tkinter, then the learning curve will be
reduced.

I've gotten all the approropriate resources for learning Python (docs,
books, tutorials), so my question is this: are there any "gotchas" that
Tcl programmers often encounter in learning Python? I'm thinking
specifically about habits that may require "unlearning," for instance,
such as grokking object orientation (Tcl procedures are now embedded
deep in my brain).

Any advice, particularly from other programmers with a lot of experience
in Tcl, is appreciated.

- --
Cheers,

Kevin Walzer, PhD
WordTech Software - "Tame the Terminal"
http://www.wordtech-software.com
sw at wordtech-software.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDb3sLJmdQs+6YVcoRAq5xAJoCbDYeMO58yRPqid4K5WTd1+PbcgCbBATL
0UppdVmVdcb+AfFUIsvrdrY=
=Hk8w
-----END PGP SIGNATURE-----

 

[Cameron Laird]

.
.
.

I've gotten all the approropriate resources for learning Python (docs,
books, tutorials), so my question is this: are there any "gotchas" that
Tcl programmers often encounter in learning Python? I'm thinking
specifically about habits that may require "unlearning," for instance,
such as grokking object orientation (Tcl procedures are now embedded
deep in my brain).

Any advice, particularly from other programmers with a lot of experience
in Tcl, is appreciated.

.
.
.
No, for the most part. Python's so wonderful that
it will immediately and correctly identify the "false
friends" you happen to type.

For the most part. If you are sufficiently steeped
in Tcl, you might find it hard to remember powerful
Python idioms--that dictionaries are first-class
objects perfectly suitable for passing, how to make
use of the different quoting syntaxes, that it's
easy to define your own Exceptions and Classes, and
so on.

You'll do fine.

 

[George Sakkis]

I've gotten all the approropriate resources for learning Python (docs,
books, tutorials), so my question is this: are there any "gotchas" that
Tcl programmers often encounter in learning Python? I'm thinking
specifically about habits that may require "unlearning," for instance,
such as grokking object orientation (Tcl procedures are now embedded
deep in my brain).

I don't know Tcl, but python doesn't force you to be OO; you can write
100% procedural code if you want to. OTOH, you'll probably need other
people's code that is OO, so at the very least you'll have to be able
to read and use it. Fortunately, using an existing OO module/library is
much easier than designing and writing it, so you can get away with it
with little effort.

George

 

[Russell E. Owen]

I'm a Tcl/Tk developer who has been dabbling with Python for some time,...
Well, I have finally found a good reason to learn Python in more depth:...

Any advice, particularly from other programmers with a lot of experience
in Tcl, is appreciated.

In Tkinter you don't name widgets to specify their hierarchy; instead
when you create a new widget you specify it's parent. A tk name does get
generated for you, but you'll never need it.

You can set and get properties on Tkinter widgets using dictionary
notation:
curr_value = wdg["property_name"]
wdg["property_name"] = new_value
this is very convenient if you don't want to set a lot of properties at
once.

Grid in Tkinter has less useful defaults than in tk. You should probably
specify row and column when using Tkinter's gridder.

If you try to mix tk and Tkinter, beware of Tkinter objects that clean
up after themselves. For instance a tkFont.Font object represents a
named font in tk, but if you lose all references to it in python, the
named font in tk is destroyed.

Features of Python that are well integrated and well worth using include:
- objects
- collection classes (including list, dict and set)
- exception handling
- default arguments for functions

tcl is a unusual in its desire to parse every string as a command. It
has plusses and minuses, but in any case, you'll have to learn to do
without (as you would when switching to almost any other language).

-- Russell

 

[Cameron Laird]

.
[acute observations]
.
.

Features of Python that are well integrated and well worth using include:
- objects
- collection classes (including list, dict and set)
- exception handling
- default arguments for functions

.
.
.
Tcl procedures roughly correspond to Python functions.
The arguments of Tcl procedures can have defaults.

I find the rest of the summary quite apt.

 

[Robert Hicks]

Ah, another one leaves the fold... : \

Robert

 

[Steve M]

Even though its for any (not just Tcl) experienced programmer, and even
though you've got all the appropriate resources, I'll mention that you
should get a lot out of the book Dive Into Python, at
http://www.diveintopython.org/

 

[Svenn Are Bjerkem]

Ah, another one leaves the fold... : \

I think I saw somebody say about OO in Python: "It's there, but you
don't have to use it." Every time somebody wants OO in the core of tcl,
he is asked: "Why do you want it?"

If OO was as easy in Tcl as in Python, there would be no real reason to
switch in my opinion. (And maybe simpler namespaces and passing of lists
to functions, we all love the uplevel and upvar commands, don't we?)

 

[Robert Hicks]

I think I saw somebody say about OO in Python: "It's there, but you
don't have to use it." Every time somebody wants OO in the core of tcl,
he is asked: "Why do you want it?"

If OO was as easy in Tcl as in Python, there would be no real reason to
switch in my opinion. (And maybe simpler namespaces and passing of lists
to functions, we all love the uplevel and upvar commands, don't we?)

That is a misconception. There are several really good packages for OO
in Tcl. XOTcl, [incr] Tcl, and my favorite Snit.

On top of that there is currently being added OO to the core of Tcl as
well. That should all be integrated in when 8.5 comes out in the
spring.

Tk is getting a native L&F uplift as well.

However, I think it is more perception than function now.

Robert

 

[Svenn Are Bjerkem]

That is a misconception. There are several really good packages for OO
in Tcl. XOTcl, [incr] Tcl, and my favorite Snit.

None of which are core functions. As I stated, there is currently no OO
in the core like in python.

On top of that there is currently being added OO to the core of Tcl as
well. That should all be integrated in when 8.5 comes out in the
spring.

Which once again is a confirmation that my statement was correct about
missing OO in the current core.

Tk is getting a native L&F uplift as well.

This is just eye candy, Tkinter was long time GUI for python and no
reason to move from Tcl to python. Today you can choose about any
toolkit for python and Tcl still has rusty old Tk.

It is all a question what you want to solve and how you want to solve
it. Tcl/Tk was once the best way to write "throwaway" applications with
a GUI, and it still is, in my opinion, but then I know too little python
so far.

(and python can not do "set result [exec someprog << $input]" as far as
I know)

 

[Robert Hicks]

Why does there need to be OO "in the core"? That is one thing I have
never understood. If you want OO, get a package that fits your style of
OO and "package require" you are off and running. That probably isn't
what you would be looking at Tcl for anyway.

I agree about Tk and I am actually talking with someone about adding a
wxTcl to the mix as well. I think wx is a much better toolkit.

It is all a question what you want to solve and how you want to solve
it.

That is so true.

Robert

 

[Grant Edwards]

(and python can not do "set result [exec someprog << $input]"
as far as I know)

I don't remember Tcl very well, but doesn't this do the same
thing?

result = os.popen('someprog','r').read()

 

[Fredrik Lundh]

(and python can not do "set result [exec someprog << $input]" as far as
I know)

execute a pro

import subprocess

</F>

 

[Svenn Are Bjerkem]

Why does there need to be OO "in the core"? That is one thing I have
never understood. If you want OO, get a package that fits your style of
OO and "package require" you are off and running. That probably isn't
what you would be looking at Tcl for anyway.

We are now starting the normal discussion that tcl'ers have about OO in
the core, and thus just whipping up old dirt. For people like me who has
invested a lot of time to learn a language that I use to solve everyday
problems, it would be nice if I could continue to use that same language
to do more advanced stuff. Loading packages is a work-around in my eyes,
and I am actually following your advice of looking at a different
language, that's why I am here in the first place. There is no need to
wear rubber boots at a party if you can wear sneakers.

 

[Roy Smith]

Why does there need to be OO "in the core"? That is one thing I have
never understood. If you want OO, get a package that fits your style of
OO and "package require" you are off and running. That probably isn't
what you would be looking at Tcl for anyway.

The problem there is that you end up with N different implementations.
They each have roughly similar capabilities, but are different enough in
the details that somebody who knows one will have trouble maintaining code
using another. Each one probably has some features which make it better
than the others in some ways, and some ugly warts too. None is superior
enough in all respects to become dominant.

It's just like C++ went through with strings and containers before STL came
along. Everybody rolled their own, or bought one of the several
commercially available libraries. That meant you could be an expert at C++
and still have a steep learning curve when coming into a new project.