Discussion:
No module named _tkinter
Carl Lowenstein
2008-05-01 17:20:19 UTC
Permalink
Trying to install a program (PySolFC) that is built on Python. I get
this error message:

File "/usr/local/lib/python2.5/lib-tk/Tkinter.py", line 38, in <module>
import _tkinter # If this fails your Python may not be configured for Tk
No module named _tkinter

What Python do I have?

[***@delta PySolFC-1.1]$ which python
/usr/local/bin/python
[***@delta tmp]$ python --version
Python 2.5

I find in the sourcesfrom which I built Python2.5 a file
/usr/local/src/Python-2.5/Modules/_tkinter.c but do not find any
corresponding .o file. The README file states:

Tkinter
-------
The setup.py script automatically configures this when it detects a
usable Tcl/Tk installation. This requires Tcl/Tk version 8.0 or
higher.

Look for evidence of Tcl/Tk version:
[***@delta yum]$ grep tcl /var/log/rpmpkgs
tcl-8.4.7-2.i386.rpm
tclx-8.3.5-4.i386.rpm

What do you suppose I didn't do.

carl
--
carl lowenstein marine physical lab u.c. san diego
***@ucsd.edu
R P Herrold
2008-05-01 17:28:30 UTC
Permalink
Post by Carl Lowenstein
/usr/local/lib/python2.5/lib-tk/Tkinter.py
hmmm -- a local, non packaged non-RH based 'latest and
greatest' Python; [/usr/local/... is not used by them]. I'd
wager it is 'along side' the distribution's Python, and path
issues rear their ugly head.
Post by Carl Lowenstein
Trying to install a program (PySolFC) that is built on Python. I get
tcl-8.4.7-2.i386.rpm
tclx-8.3.5-4.i386.rpm
What do you suppose I didn't do.
install package: tkinter ? I see it in CentOS 5

-- Russ herrold
Lan Barnes
2008-05-01 17:35:10 UTC
Permalink
Post by R P Herrold
Post by Carl Lowenstein
/usr/local/lib/python2.5/lib-tk/Tkinter.py
hmmm -- a local, non packaged non-RH based 'latest and
greatest' Python; [/usr/local/... is not used by them]. I'd
wager it is 'along side' the distribution's Python, and path
issues rear their ugly head.
Post by Carl Lowenstein
Trying to install a program (PySolFC) that is built on Python. I get
tcl-8.4.7-2.i386.rpm
tclx-8.3.5-4.i386.rpm
What do you suppose I didn't do.
install package: tkinter ? I see it in CentOS 5
-- Russ herrold
It's a sad observation that RH has dropped Tcl/Tk from the standard
distributions. Use yum for \*tcl\* and tk\* and you may experience more
joy.

This has become part of Lan's install procedure these days.
--
Lan Barnes

SCM Analyst Linux Guy
Tcl/Tk Enthusiast Biodiesel Brewer
R P Herrold
2008-05-01 17:44:47 UTC
Permalink
Post by Lan Barnes
It's a sad observation that RH has dropped Tcl/Tk from the
standard distributions. Use yum for \*tcl\* and tk\* and you
may experience more joy.
?? I fought mightily to keep them in Red Hat back in RHL days
on testers-list, but I fear their days are numbered, as new
shiny widget sets gain mindshare. Modernity for its own sake
is the rule, it seems.

Tk and Tcl are in all variants of RHEL so far, and as 'expect'
Requires: libtcl, it is somewhat challenging to completely rip
out.

An irrational distaste by the Pythonistas like this hurts, as
well:

Date: Tue, 04 Nov 2003 15:56:31 -0500
From: Havoc Pennington <***@redhat.com>
Reply-To: fedora-devel-***@redhat.com
To: fedora-devel-***@redhat.com
Subject: Re: Question about development languages
Post by Lan Barnes
I was browsing the Fedora website and noticed that the
configuration tools are said to be all Python based with a
few PyGTK ones. I don't know Python at all but am very
familiar with Perl and PerlTk. Do the tools HAVE to be
written in Python or are other languages acceptable?
Tk is unacceptable, it has to be a modern toolkit. Perl is
maybe acceptable (others may disagree) but my concern would be
more with Perl/GTK bindings, I'm not sure what their status
is. The pygtk bindings do require a fair bit of "babysitting"
to keep in a good state.

Havoc
Lan Barnes
2008-05-01 17:53:16 UTC
Permalink
Post by R P Herrold
Tk is unacceptable, it has to be a modern toolkit. Perl is
maybe acceptable (others may disagree)
???!!!

Yes, others do. Vehemently.

Let me charitably interpret this as "Tcl/Tk is _perceived_ as being old
news by the 'oh it's new, shiny' crowd."

With the advent of tile, Tk widgets in Tcl evel look like windoze, no that
that's necessarily an endorsement.

Me, I like SW that works and scripting languages that are fast,
expressive, easy to write, maintain, and scale well. And did I mention
truely cross-platform?
--
Lan Barnes

SCM Analyst Linux Guy
Tcl/Tk Enthusiast Biodiesel Brewer
R P Herrold
2008-05-01 17:55:26 UTC
Permalink
Post by Lan Barnes
Post by R P Herrold
Tk is unacceptable, it has to be a modern toolkit. Perl is
maybe acceptable (others may disagree)
???!!!
Yes, others do. Vehemently.
You'll note I was quoting an @redhat.com of some prominence at
the time of the post. Not my feelings at all.

-- Russ herrold
Doug LaRue
2008-05-01 18:02:19 UTC
Permalink
** Reply to message from "Lan Barnes" <***@falleagle.net> on Thu, 1 May 2008
12:53:12 -0700 (PDT)
Post by Lan Barnes
Let me charitably interpret this as "Tcl/Tk is _perceived_ as being old
news by the 'oh it's new, shiny' crowd."
naw, it because Python has a cool name and is named after a cool show:
"Monty Pythons Flying Circus". ;-)

I'm not sure why it's gained in popularity but over the past 5 years, its
popularity has grown considerably. From what I read, it dates back to the
early 90's so it's not THAT new. Something/someone seems to have gained
it attention and general acceptance and that means marketshare/mindshare.

Doug
R P Herrold
2008-05-01 18:11:18 UTC
Permalink
Post by Doug LaRue
Post by Lan Barnes
Let me charitably interpret this as "Tcl/Tk is _perceived_ as being old
news by the 'oh it's new, shiny' crowd."
"Monty Pythons Flying Circus". ;-)
/me thinks: so: Tcl/Tk needs to look up play its part?

The Dead Collector: Bring out yer dead.
[a man puts a body on the cart]
Large Man with Dead Body: Here's one.
The Dead Collector: That'll be ninepence.
The Dead Body That Claims It Isn't: I'm not dead.
The Dead Collector: What?
Large Man with Dead Body: Nothing. There's your ninepence.
The Dead Body That Claims It Isn't: I'm not dead.
The Dead Collector: 'Ere, he says he's not dead.
Large Man with Dead Body: Yes he is.
The Dead Body That Claims It Isn't: I'm not.
The Dead Collector: He isn't.
Large Man with Dead Body: Well, he will be soon, he's very ill.
The Dead Body That Claims It Isn't: I'm getting better.
Large Man with Dead Body: No you're not, you'll be stone dead
in a moment.

;(
- R
Lan Barnes
2008-05-01 18:15:25 UTC
Permalink
Post by Doug LaRue
12:53:12 -0700 (PDT)
Post by Lan Barnes
Let me charitably interpret this as "Tcl/Tk is _perceived_ as being old
news by the 'oh it's new, shiny' crowd."
"Monty Pythons Flying Circus". ;-)
I'm not sure why it's gained in popularity but over the past 5 years, its
popularity has grown considerably. From what I read, it dates back to the
early 90's so it's not THAT new. Something/someone seems to have gained
it attention and general acceptance and that means marketshare/mindshare.
I have problems philisophically with scripting languages that make
different types of white space significant (and, yes, make, I'm talking
about you, too). But mostly I'm not an OO guy and prefer not to malign a
language I don't know, especially when so many smart friends like it.
--
Lan Barnes

SCM Analyst Linux Guy
Tcl/Tk Enthusiast Biodiesel Brewer
Andrew Lentvorski
2008-05-01 18:34:17 UTC
Permalink
Post by Doug LaRue
I'm not sure why it's gained in popularity but over the past 5 years, its
popularity has grown considerably. From what I read, it dates back to the
early 90's so it's not THAT new. Something/someone seems to have gained
it attention and general acceptance and that means marketshare/mindshare.
It's because Guido grew a beard.

http://blogs.microsoft.co.il/blogs/tamir/archive/2008/04/28/computer-languages-and-facial-hair-take-two.aspx

-a
Doug LaRue
2008-05-01 18:39:11 UTC
Permalink
** Reply to message from Andrew Lentvorski <***@allcaps.org> on Thu, 01 May
2008 13:32:53 -0700
Post by Andrew Lentvorski
It's because Guido grew a beard.
http://blogs.microsoft.co.il/blogs/tamir/archive/2008/04/28/computer-languages-and-facial-hair-take-two.aspx
LoL....ok, now Python rocks! ;-)

Doug
Andrew Lentvorski
2008-05-01 18:46:23 UTC
Permalink
Post by Lan Barnes
Post by R P Herrold
Tk is unacceptable, it has to be a modern toolkit. Perl is
maybe acceptable (others may disagree)
???!!!
Yes, others do. Vehemently.
Let me charitably interpret this as "Tcl/Tk is _perceived_ as being old
news by the 'oh it's new, shiny' crowd."
Well ... There are a couple of things

The big one, IMO, was that Tcl had a wrenching transition just as a
bunch of people were starting to look around for alternatives to Perl.
The whole 8.0->8.3 transition when they finally kicked Ousterhout out of
the codebase was a lot of pain. It also didn't help that Tcl/Tk didn't
get along with Windows during that timeframe, either.

This is what got me into Python. I was looking for something better
than C++ or Perl, and Tcl/Tk was on the radar in a big way (I am an EE
and Tcl/Tk was *the* extension language of the Berkeley EE apps). But,
after dealing with a bunch of the 8.0 transition crap, I wrote it off
and learned Python.

Of course, after that, inertia sets in. Tcl/Tk is now firmly in the
same camp as Ruby, for me. Insufficiently better or different from
Python for me to waste time on it.

I was also never a big fan of [incr Tcl]. However, I'm not blind enough
to believe that's the reason I rejected the language.
Post by Lan Barnes
With the advent of tile, Tk widgets in Tcl evel look like windoze, no that
that's necessarily an endorsement.
Ooo ... ooo ... ook?

Take some time, remove the typos, fix the grammar and clarify that
statement, thanks.
Post by Lan Barnes
Me, I like SW that works and scripting languages that are fast,
expressive, easy to write, maintain, and scale well. And did I mention
truely cross-platform?
And Tcl/Tk was none of those in the 8.0->8.3 transition. In my option,
that's where Tcl/Tk lost the war.

-a
Lan Barnes
2008-05-01 19:04:02 UTC
Permalink
Post by Andrew Lentvorski
Post by Lan Barnes
With the advent of tile, Tk widgets in Tcl evel look like windoze, no that
that's necessarily an endorsement.
Ooo ... ooo ... ook?
Take some time, remove the typos, fix the grammar and clarify that
statement, thanks.
s/evel/even/ s/no/not/

And I mean that looking like windoze comforts the feeble-minded, but
doesn't necessarily improve the interface.
Post by Andrew Lentvorski
Post by Lan Barnes
Me, I like SW that works and scripting languages that are fast,
expressive, easy to write, maintain, and scale well. And did I mention
truely cross-platform?
And Tcl/Tk was none of those in the 8.0->8.3 transition.
I didn't suffer that, but acknowledge that you may exercise a language
more than I.
Post by Andrew Lentvorski
In my option,
that's where Tcl/Tk lost the war.
OK, TIME OUT!

This American propensity of viewing everything as a conflict/football
game/war leads us down many stupid roads. The war on poverty (least
unsuccessful of the many wars I've seen). The war on drugs. "My 'battle'
with cancer."

How about the right tool for the problem?
--
Lan Barnes

SCM Analyst Linux Guy
Tcl/Tk Enthusiast Biodiesel Brewer
Andrew Lentvorski
2008-05-01 19:41:18 UTC
Permalink
Post by Lan Barnes
Post by Andrew Lentvorski
In my option,
that's where Tcl/Tk lost the war.
OK, TIME OUT!
This American propensity of viewing everything as a conflict/football
game/war leads us down many stupid roads. The war on poverty (least
unsuccessful of the many wars I've seen). The war on drugs. "My 'battle'
with cancer."
How about the right tool for the problem?
Social community *is* part of "the right tool for the problem" whether
you like it or not.

And social community in things like programming language and operating
system tends to be winner take all by virtue of network effect and not
wanting to learn anything new (aka inertia). In that case,
war/conflict/football game is pretty close to the right metaphor.

Tcl may be the "right tool for the problem". But, is it a better or
different tool for the problem than Python, Ruby, Perl, etc. Probably
not by enough to switch anyone from one camp to another. See: Lua
(small), Erlang (concurrency) or Scheme/Lisp (metaprogramming) for
examples of "better or different" tool which is sufficiently so to pull
people *out* of an existing camp.

That was the Unix side. So, let's take a look at the Windows side of
the coin.

Is there a Tcl for the CLR or JVM? It appears there is for the JVM, but
the community seems pretty dead around that. Nothing obvious for the
CLR. Part of the reason why the "scripting languages" are gaining
ground on Windows is that suddenly they are "zero install". If your
code can be translated to CLR or JVM bytecode, it can be run without
requiring install permission from your local IT department.

So, on the Windows side, Tcl, in fact, seems to be a far inferior
solution than several other choices.

Social community is important. I'm sorry. I have a limited amount of
time and brainpower to expend digging things out for myself.
Occasionally, I want to be able to ask someone *else* for the solution.
The community needs to be vibrant enough that 90% of my needs are
already met even *before I know I have them*.

The Tcl community is starting to lag on that (see: lack of Gtk bindings
and CLR VM, for example). Complaining won't change that. Writing code,
finding someone to write code, or funding someone to write code are
really the only choices.

-a
Doug LaRue
2008-05-01 19:43:13 UTC
Permalink
** Reply to message from "Lan Barnes" <***@falleagle.net> on Thu, 1 May 2008
14:03:58 -0700 (PDT)
Post by Lan Barnes
Post by Andrew Lentvorski
In my option,
that's where Tcl/Tk lost the war.
OK, TIME OUT!
This American propensity of viewing everything as a conflict/football
game/war leads us down many stupid roads. The war on poverty (least
unsuccessful of the many wars I've seen). The war on drugs. "My 'battle'
with cancer."
How about the right tool for the problem?
Can't we all just get along?. ;-)

Seriously, this win/lose stuff is engrained in our society and drives nearly
all aspects of it. We strive to win and that's what makes us somewhat
successful. But also, it's our nature to find comfort in associations with like
minded people and therefore we gain more comfort when that group is
perceived as growing. It validates the decision which bound us to the group.
Simply put, these two concepts are what always brings us to comparing
everything to war or any win/lose comparison or statement.

I doubt Andrew meant "war" but just the growth for mindshare and acceptance.
Heck, I had "battle" instead of "growth"...

Or are we all just well trained warmongers and don't know it? ;-)

Doug
Paul G. Allen
2008-05-02 06:29:54 UTC
Permalink
Post by Lan Barnes
Post by R P Herrold
Tk is unacceptable, it has to be a modern toolkit. Perl is
maybe acceptable (others may disagree)
???!!!
Yes, others do. Vehemently.
Let me charitably interpret this as "Tcl/Tk is _perceived_ as being old
news by the 'oh it's new, shiny' crowd."
With the advent of tile, Tk widgets in Tcl evel look like windoze, no that
that's necessarily an endorsement.
Me, I like SW that works and scripting languages that are fast,
expressive, easy to write, maintain, and scale well. And did I mention
truely cross-platform?
You didn't mention one that have stood the test of time and have a long
history of working.

I too have used Tcl/TK and have used Perl with TK and very much liked
it. I've never understood the "It's newer so I have to use it." crowd. I
prefer "It's proven to work and has a long history of doing so."

PGA
--
Paul G. Allen, BSIT/SE
Owner, Sr. Engineer
Random Logic Consulting Services
www.randomlogic.com
Doug LaRue
2008-05-02 12:34:05 UTC
Permalink
** Reply to message from "Paul G. Allen" <***@randomlogic.com> on Fri, 02
May 2008 01:28:16 -0700
Post by Paul G. Allen
I've never understood the "It's newer so I have to use it." crowd.
there's a big difference between the linear programming crowd and
those who were brought up with some understanding that object oriented
is "new". Lan touched on the OO bit some and makes me wonder how
much isn't related to this. We know C++ brought OOP to the masses
in the late 80s but was quickly squelched with MS C-- and their attack
on the C++ frameworks market. Java in the mid/late 90s brought OOP
back and it's become a standard part of most university CS curriculum.
Smalltalk almost broke out around 1996 but Java took its thunder and
got the mindshare.

So anything which doesn't have much OO built into it is going to get the
"it's older" cold shoulder from the n00b's out of school in the last 10
years and those using different languages because of a job or client
choice.

just my take on this "it's new" / "it's old" language thang.

Doug
Lan Barnes
2008-05-02 15:03:00 UTC
Permalink
Post by Doug LaRue
May 2008 01:28:16 -0700
Post by Paul G. Allen
I've never understood the "It's newer so I have to use it." crowd.
there's a big difference between the linear programming crowd and
those who were brought up with some understanding that object oriented
is "new". Lan touched on the OO bit some and makes me wonder how
much isn't related to this. We know C++ brought OOP to the masses
in the late 80s but was quickly squelched with MS C-- and their attack
on the C++ frameworks market. Java in the mid/late 90s brought OOP
back and it's become a standard part of most university CS curriculum.
Smalltalk almost broke out around 1996 but Java took its thunder and
got the mindshare.
So anything which doesn't have much OO built into it is going to get the
"it's older" cold shoulder from the n00b's out of school in the last 10
years and those using different languages because of a job or client
choice.
just my take on this "it's new" / "it's old" language thang.
Doug
First of all, one of the reasons I break into hives when OO comes up is
because I was introduced to it through C++, which I am told by OO people
is like learning BASIC as a first language -- a cause of drain bamage. (My
other hurdle was actually trying to read Codd and Date. GMWAS.)

Secondly, I will point out that GUI/widget event-driven programming is by
its very nature object oriented. You'rs just using objects developed for
you by someone a lot smarter.

And I will say again, C is a systems language, and a lovely one at that;
C++ is C that's been all fracked up; and it baffles me that people don't
develop more apps in scripting languages. Why make life harder for
yourself?
--
Lan Barnes

SCM Analyst Linux Guy
Tcl/Tk Enthusiast Biodiesel Brewer
Doug LaRue
2008-05-02 17:08:14 UTC
Permalink
** Reply to message from "Lan Barnes" <***@falleagle.net> on Fri, 2 May 2008
10:02:55 -0700 (PDT)

Sorry, way too wordy of a response....
Post by Lan Barnes
First of all, one of the reasons I break into hives when OO comes up is
because I was introduced to it through C++, which I am told by OO people
is like learning BASIC as a first language -- a cause of drain bamage. (My
other hurdle was actually trying to read Codd and Date. GMWAS.)
I don't see how it could be said that 'learning OO using C++' can be like
'learning BASIC as a first language'. But if you tried to learn OO concepts
by doing database coding then yup, you're going to get drain bamaged
trying to figure out how OO data structures can be layed out in relational
datebases while you are still managing the relational database the old way.
OO concepts are not going to sink in when you're mixing it all up. I turned
down jobs because I was told the projects were C/C++ and after the interviews
found out the developers were doing C with the C++ compiler. This was
very common and finding a C/linear programmer willing to spend the time
learning OOP was like finding the proverbial needle in the haystack.
Post by Lan Barnes
Secondly, I will point out that GUI/widget event-driven programming is by
its very nature object oriented. You'rs just using objects developed for
you by someone a lot smarter.
That's because you "see" GUI object as an object but don't see non-visual
software as being objects. A good class library goes along way at providing
wrapped data structures, communications, and even hardware access so
that what's behind the scenes are ojects too. Borland had an OK class library,
IBM had a very nice one, Microsofts sucked because they say OO as making
Win32 obsolete. Why some like Java is because it comes with such a rich
class library, Smalltalk is the same but more "pure" OO thru and thru.
Post by Lan Barnes
And I will say again, C is a systems language, and a lovely one at that;
C++ is C that's been all fracked up; and it baffles me that people don't
develop more apps in scripting languages. Why make life harder for
yourself?
You see C as a systems language because you have alot of other options.
In the 80's, there wasn't much else which could give you the needed performance
given the hardware at the time. Why Stroustrup came up with C++, I don't
know but seeing how systems apps where throwing parts of code all across the
file system, just the one feature of wrapping data with methods seemed like
an incredible advantage. Sure one could do that with C but mostly coders did
not and having the language require this forced policy on the dev for the good
of maintaining the code. Abstraction is nice so you don't have to retest code
you are only adding a small bit to. But the problem was that C++ let you code
in C. Lazy devs will fall to C and all that brings. But C++ was/is pretty darn
fast unless you get way overboard with abstraction and object design.

You can thank Moore's Law for the ability to now use interpreted code for
full blown applications and it is happening from what I've seen on Linux.
You can also thank Moore's Law for the ability to run virtual machines for
somewhat-interpreted languages like Smalltalk, Java, and yuk, C-pound
for use in applications not "compiled' to native code. Unfortunately, what
gets popular has alot to do with what 'runtime' gets pre-installed on PCs
when they get shipped to customers. Windows is a big issue because
marketing pressure by Microsoft dictates what become popular while on
Linux, it's more what developers decide is popular.

FYI, looking at a new Ubuntu 8.04 install for apps using or running interpreted
Python code, I see:
totem, gimp, zulrunner, openoffice, deskbar-applets, gedit, rythmbox,
hplip, launchpad-integration, obviously Sugar, guidence, games, hwtests,
numeric, amarok, system-config-printer, and there are others I found on
my workstation system like gazpacho, subversion, pida, trac, graphviz,
DeVeDe, and rat all use python for either scripting or are built as python
applications.

It's getting there but unfortunately for the 'old languages' they are going to
be using mostly 'newer languages' and they will likely all support OOP.

Doug
Andrew Lentvorski
2008-05-02 19:03:42 UTC
Permalink
Post by Lan Barnes
And I will say again, C is a systems language, and a lovely one at that;
C++ is C that's been all fracked up; and it baffles me that people don't
develop more apps in scripting languages. Why make life harder for
yourself?
Well, as I pointed out, it's the "zero install" issue on Windows.

The IT staff simply will *not* allow anyone to install a non-corporate
approved language in their environment. I have seen this many times
from folks when they ask for something that results in 4 lines of regex
Perl from me. "Oh, I can't use Perl. It's not installed and I can't
possibly get permission for that. How can I use Java/C#?"

With the languages now targeting the CLR and JVM, that problem goes
away. The program "looks and smells" like the binary tools they all
use, so that passes IT muster.

Yeah, it's stupid. But it's reality.

I suspect that C++ is going to start to decline now that these languages
can sneak past the IT staff filter as bytecode.

-a
Paul G. Allen
2008-05-03 11:22:42 UTC
Permalink
Post by Andrew Lentvorski
Well, as I pointed out, it's the "zero install" issue on Windows.
The IT staff simply will *not* allow anyone to install a non-corporate
approved language in their environment. I have seen this many times
from folks when they ask for something that results in 4 lines of regex
Perl from me. "Oh, I can't use Perl. It's not installed and I can't
possibly get permission for that. How can I use Java/C#?"
I've found myself in the minority when I say to corporate and/or IT,
"You want me to do X, then I need Y, or the job doesn't get done." If
they are so stubborn that they can't provide an efficient working
environment (including functioning tool set) for me to get my job done
efficiently, then I don't need to be working there.

In my opinion, it's ITs job to provide the tools and environment needed
for the users (especially engineers and the like) to do their jobs. It's
corporates job to give IT the latitude to provide the resources so that
IT can provide that environment. To do otherwise shows a fundamental
disconnect at the core of the company, and such a disconnect sets off
warning sirens in my head.

I left a company in November with such a problem (and it still exists).
Things are not going well there.

(Aside: I *_DO_NOT_* like C#. Learned some of it at the afore mentioned
company. The first turnoff was the licensing - nightmare. The second was
that it is J++ - which was M$ modified Java - with some newer C++ stuff
thrown in, wrapped in a M$ wrapper. Java is nice because it doesn't have
some of the crap that C++ has that only causes more problems than it
solves. M$ comes along and puts that crap into C# and adds their typical
restrictive and complicated licensing to it!)

PGA
--
Paul G. Allen, BSIT/SE
Owner, Sr. Engineer
Random Logic Consulting Services
www.randomlogic.com
Doug LaRue
2008-05-03 14:19:28 UTC
Permalink
** Reply to message from "Paul G. Allen" <***@randomlogic.com> on Sat, 03
May 2008 06:20:46 -0700
Post by Paul G. Allen
In my opinion, it's ITs job to provide the tools and environment needed
for the users (especially engineers and the like) to do their jobs. It's
corporates job to give IT the latitude to provide the resources so that
IT can provide that environment. To do otherwise shows a fundamental
disconnect at the core of the company, and such a disconnect sets off
warning sirens in my head.
that kind of practice went out the window in the early 90s when Microsoft
flooded the press with lies about what its software could do and dumped
tons of marketing brochures in managements mail boxes. Management
started dictating what tools the engineers/developers were to use.

And the sad thing is that I too have seen many projects have Microsoft
software dictated as THE toolset, the projects failed for technical
reasons and nobody loses their job. It is a perpetuation of incompetence
with no corrective element built in so businesses don't do it again.
Management has the balls to dictate the Microsoft tools be does not
have the balls to take responsibility for poor judgment.

I too have left a few jobs when the technology was dictated down based
on non-technical reasons. All the fun and excitement goes out the Windows.

Doug
David Brown
2008-05-03 15:46:18 UTC
Permalink
Post by Doug LaRue
that kind of practice went out the window in the early 90s when Microsoft
flooded the press with lies about what its software could do and dumped
tons of marketing brochures in managements mail boxes. Management
started dictating what tools the engineers/developers were to use.
What's amazing is when engineering even has to have a discussion as to why
Linux development should be done on Linux machines.

It still doesn't stop them from sending a side group off to try and figure
out if they can setup a cross-compilation environment from windows
machines. Fortunately, the cross compilation environment is very difficult
to set up, and they've decided it's worth buying linux machines for people
doing linux development.

David

Doug LaRue
2008-05-01 17:54:35 UTC
Permalink
** Reply to message from R P Herrold <***@owlriver.com> on Thu, 1 May 2008
15:44:43 -0400 (EDT)
Irrational? It is far more likely that it is just the preference of the
younger crowd coming in and working on Linux software. Look at
those Tcl/Tk'ers who'll not even bother trying Python because they
know what they know and aren't interested in learning something new.
It's the same thing but in reverse and today, Python gets mindshare
so it gets the preference. Makes sense to me.

Doug
Brad Beyenhof
2008-05-01 17:35:49 UTC
Permalink
Post by R P Herrold
Post by Carl Lowenstein
/usr/local/lib/python2.5/lib-tk/Tkinter.py
install package: tkinter ? I see it in CentOS 5
Does your distro have a "python-tk" package? Ubuntu 8.04 doesn't have
a package named tkinter, but python-tk seems to provide that
functionality.
--
Brad Beyenhof http://augmentedfourth.com
Have the courage to be ignorant of a great number of things, in order to
avoid the calamity of being ignorant of everything.
~ Sydney Smith, English essayist and preacher (1771-1845)
Carl Lowenstein
2008-05-01 20:19:07 UTC
Permalink
Post by Carl Lowenstein
/usr/local/lib/python2.5/lib-tk/Tkinter.py
hmmm -- a local, non packaged non-RH based 'latest and greatest' Python;
[/usr/local/... is not used by them]. I'd wager it is 'along side' the
distribution's Python, and path issues rear their ugly head.
Well, I needed the 'latest and greatest' Python for some other uses,
and built it myself because this system is Fedora Core 3 at heart.
The distribution's Python has, among other things,
/usr/lib/python2.3/lib-tk/Tkinter.py
As far as I can tell, each Python keeps to itself.
Post by Carl Lowenstein
Trying to install a program (PySolFC) that is built on Python. I get
tcl-8.4.7-2.i386.rpm
tclx-8.3.5-4.i386.rpm
What do you suppose I didn't do.
install package: tkinter ? I see it in CentOS 5
grep tk /var/log/rpmpkgs # produces some 20 lines, including these two

tk-8.4.7-2.i386.rpm
tkinter-2.3.4-13.1.i386.rpm

Again, as far as I can tell, it is not that tkinter is missing. It is
that the compiled version of Python does not reference it at all.

carl
--
carl lowenstein marine physical lab u.c. san diego
***@ucsd.edu
Doug LaRue
2008-05-01 20:24:29 UTC
Permalink
** Reply to message from "Carl Lowenstein" <***@gmail.com> on Thu,
1 May 2008 15:19:06 -0700
Post by Carl Lowenstein
/usr/lib/python2.3/lib-tk/Tkinter.py
As far as I can tell, each Python keeps to itself.
looks like if you test python2.3 for _tkinter and it passes then you
found the problem and maybe just copying the lib-tk over to the
newer python will get you going.

Doug
Carl Lowenstein
2008-05-01 21:11:05 UTC
Permalink
Solved for the moment. See below.

On Thu, May 1, 2008 at 3:19 PM, Carl Lowenstein
Post by Carl Lowenstein
Post by Carl Lowenstein
/usr/local/lib/python2.5/lib-tk/Tkinter.py
hmmm -- a local, non packaged non-RH based 'latest and greatest' Python;
[/usr/local/... is not used by them]. I'd wager it is 'along side' the
distribution's Python, and path issues rear their ugly head.
Well, I needed the 'latest and greatest' Python for some other uses,
and built it myself because this system is Fedora Core 3 at heart.
The distribution's Python has, among other things,
/usr/lib/python2.3/lib-tk/Tkinter.py
As far as I can tell, each Python keeps to itself.
Post by Carl Lowenstein
Trying to install a program (PySolFC) that is built on Python. I get
tcl-8.4.7-2.i386.rpm
tclx-8.3.5-4.i386.rpm
What do you suppose I didn't do.
install package: tkinter ? I see it in CentOS 5
grep tk /var/log/rpmpkgs # produces some 20 lines, including these two
tk-8.4.7-2.i386.rpm
tkinter-2.3.4-13.1.i386.rpm
Again, as far as I can tell, it is not that tkinter is missing. It is
that the compiled version of Python does not reference it at all.
Careful reading of the log from when I compiled Python-2.5 in
September 2006 shows that Tcl/Tk and friends were apparently not
present on the system at that time. Recompiling gives me Python-2.5
without this deficiency.

Bah. But it did give a marvelous opportunity to watch the Tcl/Tk and
Python fans express themselves at length.

carl
--
carl lowenstein marine physical lab u.c. san diego
***@ucsd.edu
Paul G. Allen
2008-05-02 09:45:17 UTC
Permalink
Post by Carl Lowenstein
Careful reading of the log from when I compiled Python-2.5 in
September 2006 shows that Tcl/Tk and friends were apparently not
present on the system at that time. Recompiling gives me Python-2.5
without this deficiency.
Bah. But it did give a marvelous opportunity to watch the Tcl/Tk and
Python fans express themselves at length.
I think Carl planned this all along just to start the debate. :)

PGA
--
Paul G. Allen, BSIT/SE
Owner, Sr. Engineer
Random Logic Consulting Services
www.randomlogic.com
Doug LaRue
2008-05-01 17:38:29 UTC
Permalink
** Reply to message from "Carl Lowenstein" <***@gmail.com> on Thu,
1 May 2008 12:20:15 -0700
Post by Carl Lowenstein
tcl-8.4.7-2.i386.rpm
tclx-8.3.5-4.i386.rpm
where is Tk?

Doug
Carl Lowenstein
2008-05-01 20:13:44 UTC
Permalink
Post by Doug LaRue
1 May 2008 12:20:15 -0700
Post by Carl Lowenstein
tcl-8.4.7-2.i386.rpm
tclx-8.3.5-4.i386.rpm
where is Tk?
Installed somewhere.

grep tk /var/log/rpmpkgs # gives about 20 lines, of which two at the end are:
tk-8.4.7-2.i386.rpm
tkinter-2.3.4-13.1.i386.rpm

carl
--
carl lowenstein marine physical lab u.c. san diego
***@ucsd.edu
Doug LaRue
2008-05-01 20:21:10 UTC
Permalink
** Reply to message from "Carl Lowenstein" <***@gmail.com> on Thu,
1 May 2008 15:13:41 -0700
Post by Carl Lowenstein
tk-8.4.7-2.i386.rpm
tkinter-2.3.4-13.1.i386.rpm
No python binding for tkinter....
I don't have tcl installed, have tk8.4 installed and have python-tk installed.
This does not complain about tkinter:

import sys
import _tkinter

print "hello"
print sys.version

Doug
James G. Sack (jim)
2008-05-01 20:36:11 UTC
Permalink
Post by Carl Lowenstein
Post by Doug LaRue
1 May 2008 12:20:15 -0700
Post by Carl Lowenstein
tcl-8.4.7-2.i386.rpm
tclx-8.3.5-4.i386.rpm
where is Tk?
Installed somewhere.
tk-8.4.7-2.i386.rpm
tkinter-2.3.4-13.1.i386.rpm
carl
I get
rpm -q tkinter
tkinter-2.5-15.fc7
rpm -ql tkinter | grep _tkinter\.so
/usr/lib64/python2.5/lib-dynload/_tkinter.so
rpm -ql tkinter | grep Tkinter\.py
/usr/lib64/python2.5/lib-tk/Tkinter.py
and pydoc Tkinter gives a nice man page (if you have pydoc)

Hmmm, what was the problem you were having again? Maybe you didn't post
the entire traceback, and the error was other than it appeared?

Can you run the interactive shell and load Tkinter.py?
python
Post by Carl Lowenstein
Post by Doug LaRue
Post by Carl Lowenstein
import Tkinter
dir(Tkinter)
dir(Tkinter._tkinter)
(^D to exit)
Regards,
..jim
Gus Wirth
2008-05-01 21:20:45 UTC
Permalink
Post by Carl Lowenstein
Trying to install a program (PySolFC) that is built on Python. I get
File "/usr/local/lib/python2.5/lib-tk/Tkinter.py", line 38, in <module>
import _tkinter # If this fails your Python may not be configured for Tk
No module named _tkinter
What Python do I have?
/usr/local/bin/python
Python 2.5
I find in the sourcesfrom which I built Python2.5 a file
/usr/local/src/Python-2.5/Modules/_tkinter.c but do not find any
Tkinter
-------
The setup.py script automatically configures this when it detects a
usable Tcl/Tk installation. This requires Tcl/Tk version 8.0 or
higher.
tcl-8.4.7-2.i386.rpm
tclx-8.3.5-4.i386.rpm
What do you suppose I didn't do.
You need to install the development packages tcl-devel and tclx-devel.
The devel packages provide the header files and some libraries needed
for compilation of the Python module.

Gus
Loading...