Python differences between running as a script and running through an interactive shell

Question

I am trying to debug a problem using the ctypes shell from Windows DLLs and have noticed differences when I run tests through an interactive shell (python or ipython) and when I run scripts non-interactively.

I was wondering if there is any explanation for the differences that I see here?

In particular, when I run a simple test interactively, the DLL call will hang and never return, where exactly the same code as the script will not demonstrate this problem.

To be more clear what I mean here, imagine you have the following code

from foobar import bar, foo bar(foo(1,2,3)) 

When you insert a file, say, “myfoo.py” and excecuted through “python myfoo.py”, the above code executes as expected. However, if you enter the above into the python / ipython shell, the code behaves differently (in my case it hangs when the ctypes.WinDLL function is called)

Additional information:

I use the same interpreter and the same PYTHONPATH in both cases. The wrapped DLL is Canon EDSDKv2.9, an SDK for remotely controlling cameras. It always hangs in a DLL, not in python code.

Upon initialization, my EDSDK wrapper launches a thread whose execution method is as follows:

  def run(self): sys.coinit_flags = 0 #use multithreaded mode from pythoncom import PumpWaitingMessages #^^ done here so this thread is correctly initialised error(EDSDK.EdsInitializeSDK()) self.EDSDK_initialised = True while self.active: PumpWaitingMessages() sleep(self.msg_sleep_time) error(EDSDK.EdsTerminateSDK()) 

The purpose of these threads is to initialize the SDK, send messages, and allow other threads to call wrapped methods.

Note: in previous versions of EDSDK, this worked both interactively and interactively. My current problem only occurs in the latest version of EDSDK.

I suspect that this may be due to streams (hence the fragment), but cannot find any information on the Internet to support my suspicions.

So, does anyone know of any differences when starting python interactively and not interactively? Perhaps related to window threads? Any help, even wild guesses, will be appreciated on this subject, because I'm completely at a standstill! :)

Answer 1

The interactive Python interpreter is not thread safe. So, if you try to send a lock command, the entire interpreter will hang.

See this article about why this happens (tl; dr is that IDLE and threads don't mix). As for how to fix this, use the console, not the GUID IDLE. Or you can just use a script.

Answer 2

This must be borne in mind in the context of asynchronous or parallel operations (for example, multithreading, multiprocessing). In all senses and tasks, when you use Python interactively, you don't have a main loop. Even if __name__ set to __main__ , everything assigned or executed there may not be available. This is especially true for multiprocessing, and in some cases for multithreading, when the state of objects may not be shared between processes / threads.

This behavior can be confusing at best and dangerous at worst. It’s a good habit to enter when debugging should always point your threads and combine them using the Python logging module to track what happens behind the scenes.