f



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

-----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-----
0
sw3259 (273)
11/7/2005 4:04:27 PM
comp.lang.python 77058 articles. 6 followers. Post Follow

14 Replies
266 Views

Similar Articles

[PageSpeed] 22

In article <ef6d2$436f7b11$4275d90a$30783@FUSE.NET>,
Kevin Walzer  <sw@wordtech-software.com> wrote:
			.
			.
			.
>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.
0
claird (2363)
11/7/2005 7:08:02 PM
"Kevin Walzer" <sw@wordtech-software.com> wrote:

> 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

0
gsakkis (345)
11/7/2005 7:26:31 PM
In article <ef6d2$436f7b11$4275d90a$30783@FUSE.NET>,
 Kevin Walzer <sw@wordtech-software.com> wrote:

>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
0
rowen (125)
11/8/2005 6:29:04 PM
In article <rowen-E98D49.10290408112005@gnus01.u.washington.edu>,
Russell E. Owen <rowen@cesmail.net> wrote:
			.
		[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.
0
claird (2363)
11/8/2005 11:08:03 PM
Ah, another one leaves the fold...  : \

Robert

0
sigzero (1319)
11/9/2005 2:22:47 AM
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/

0
sjmaster (65)
11/9/2005 6:08:06 AM
In article <1131502967.138632.94840@g47g2000cwa.googlegroups.com>, 
sigzero@gmail.com says...
> 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?)
-- 
Svenn
0
svenn.are (446)
11/9/2005 8:01:55 AM
Svenn Are Bjerkem wrote:
> In article <1131502967.138632.94840@g47g2000cwa.googlegroups.com>,
> sigzero@gmail.com says...
> > 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?)
> --
> Svenn

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

0
sigzero (1319)
11/9/2005 4:00:39 PM
In article <1131552039.774736.298520@z14g2000cwz.googlegroups.com>, 
sigzero@gmail.com says...
> 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)



-- 
Svenn
0
svenn.are (446)
11/10/2005 2:41:42 PM
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

0
sigzero (1319)
11/10/2005 3:56:49 PM
On 2005-11-10, Svenn Are Bjerkem <svenn.are@bjerkem.de> wrote:

> (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()

-- 
Grant Edwards                   grante             Yow!  I have a VISION! It's
                                  at               a RANCID double-FISHWICH on
                               visi.com            an ENRICHED BUN!!
0
grante (5416)
11/10/2005 3:58:09 PM
Svenn Are Bjerkem wrote:

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

execute a pro

import subprocess

</F>



0
fredrik2101 (5275)
11/10/2005 4:37:19 PM
In article <1131638209.485738.276940@z14g2000cwz.googlegroups.com>, 
sigzero@gmail.com says...
> 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.

-- 
Svenn
0
svenn.are (446)
11/11/2005 7:23:17 AM
"Robert Hicks" <sigzero@gmail.com> wrote:
> 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.
0
roy (2295)
11/11/2005 1:41:47 PM
Reply: