Weird problems with import and IDLE

[Steven Taschuk]

Quoth David Reis:
> Thanks a lot for your detailled response and for not quitting reading
> after 2 lines due to my writing style *g*.

It was, I admit, a close thing.  But no one else had responded
after several hours, so I thought I'd take the opportunity to
build up some good karma.

With the additional information you supplied, I now have a few
comments and suggestions which you might find helpful.

First, I think there's more than one problem underlying the
symptoms you describe.  (I've reordered the quoted material below
accordingly.)

  [problem 1: accessing contents of imported modules]

> if key=="random.": key=keyrand(7) ## keyrand(int) is defined in
>                                   ## crypttools, though, the error
>                                   ## occurs

Try this:
	key = crypttools.keyrand(7)

('import foo' puts just 'foo' into the namespace; its contents are
then 'foo.bar', 'foo.snee', etc..  If you want to be able to write
just 'bar' and 'snee' instead, you need 'from foo import bar,
snee' or 'from foo import *'.)

  [problem 2: getting modules imported in the first place]

> import crypttools  ## This is the module which fails first, but works in
>                    ## DOS.
> import code        ## These are in the same dir as crypttools and fail,
> import decode      ## too, if I remove crypttools import
> import socket      ## If I cut the three above ones out, these work.
> import time        ## .--'
> import thread      ## .-'
> import string      ## .'

This certainly looks like a search path problem, as you said in
the first place.  I don't see anything wrong with the
configuration you described, but I should warn you that this
doesn't mean much -- I've never run Python on any version of
Windows and don't know if there are differences that might be
relevant.  (Perhaps someone with more experience in this area will
chime in.)

You say that the 'import crypttools' "fails first but works in
DOS"; just to clarify, do you mean it failed in IDLE back when
IDLE was working, but works now, running from the command line?

If 'import crypttools' is working now, but the imports of other
files in the same directory aren't, then I wonder whether that
import is actually getting the module you think.  To find out, try
this:
	C:\TOOLS\CODING\PYTHON> python
	Python 2.2.2 [...]
	Type "help", "copyright", "credits" or "license" for more information.
	>>> import crypttools
	>>> crypttools.__file__
This will tell you the absolute path of the file that the module
was loaded from.  Also try this when your current directory is
c:\tools\coding\python\chat, and when it's, say, c:\temp.

I'd also like to know whether importing modules other than those
in the standard library *always* fails, or fails only in the chat
program.  To find out, try this:  Go to some random directory
(say, c:\temp) and create a file spam.py, containing
	# spam.py
	three = 3
Then do
	C:\TEMP> set PYTHONPATH=.
	C:\TEMP> python
	Python 2.2.2 [...]
	Type "help", "copyright", "credits" or "license" for more information.
	>>> import spam
	>>> print spam.three
What happens?

It's probably not useful, but just in case: what is the error
message and traceback when 'import code' and 'import decode' fail?

  [problem 3: opening files with relative paths]

> options=open("/tools/coding/python/chat/options.ini") ## This way works
> motd=open("motd.txt")      ## The path error; motd is in above path
  [...]
> - Without a strict path in DOS it looks like this:
> Traceback (Most recent call last):
>   File: "chat/chat.py", line 15, in ?
>    options=open("options.ini")
> IOError [Errno 2] No such file or directory: 'options.ini'
  [...]
> I execute python.exe from c:\tools\coding\python. Moving it to the same
> dir like the code doesen't help, so it doesen't seem to be dependent on
> the current directory.

If this is the situation:
	C:\TOOLS\CODING\PYTHON> dir /w chat
	chat.py   options.ini  [...other files...]
	C:\TOOLS\CODING\PYTHON> python chat/chat.py
	... IOError 'no such file' as described above
then I'm not surprised.  The relative path "options.ini" here
would mean c:\tools\coding\python\options.ini, and no such file
exists.  The relative path "chat/options.ini", however, should
work.  (Or "chat\\options.ini" if Python on Windows needs
backslashes in path names.)  Does it?

I'm not entirely sure from the last blurb above whether the 'no
such file' IOError also happens in this situation:
	C:\TOOLS\CODING\PYTHON\CHAT> dir /w
	chat.py   options.ini  [...other files...]
	C:\TOOLS\CODING\PYTHON\CHAT> python chat.py
	... IOError?
(Note that this is with a different current directory than
before.)  If the IOError also occurs in this situation, I'll be
surprised.  Does it?

On relative paths generally:  You're right that relative paths
should work, though they will be interpreted relative to the
current directory, not relative to the directory of the code.  If
you want to open a configuration file which should be in the same
directory as the code, and be able to do this no matter what the
user's current directory when your program is invoked...  I don't
see how that can be done without the program knowing the absolute
path of the directory in which it was installed.  There's various
methods of doing this... but I digress.

  [problem 4: broken IDLE]

> [...] I installed it completely new once, IDLEfork too, it
> changed nothing. (No dll problems, PLEASE....)
  [...]
> It just does absolutely nothing. You could think there is a short
> flashing of the mouse pointer where it'd normally show the hourglass,
> but nothing else. And there is no process running I wouldn't know.

Aha!  The flashing mouse pointer bug!  Well, then you have to...

No, I'm faking it.  I'm afraid I really have no idea what could be
wrong with IDLE.

Can you run it in a debugger?

-- 
Steven Taschuk                             staschuk at telusplanet.net
"I may be wrong but I'm positive."  -- _Friday_, Robert A. Heinlein