import error with _strptime

[GoogleCodeExporter]

With the Pylons site Ben Bangert is seeing lots of errors about importing 
_strptime.  This thread seems to describe the same problem:

http://www.gossamer-threads.com/lists/engine?
do=post_view_printable;post=755342;list=python

Under the same load and another server the application never shows this 
(it's also an error I've never seen, in many other containers).  So it seems 
like it is probably a mod_wsgi problem.

We're trying to put "import time" into the application loading file, which 
might fix this, but perhaps it's something that should happen automatically 
(time will see if the import time workaround helps).

Original issue reported on code.google.com by ianbick...@gmail.com on 27 Jan 2010 at 11:14

[GoogleCodeExporter]

I knew about this. The PyImport_ImportModuleNoBlock() function has got to be 
one of the most stupid functions I 
have seen because it is a disaster waiting to happen. I could never understand 
why it is being used in the standard 
library modules given the problems it will inevitably cause in multithread 
programs which don't preload everything.

The questionability of using/having this function in Python should be raised on 
python-dev list.

As workaround, all I can suggest is for all modules in standard library which 
are imported in this way, that you 
import them up front from a script designated to be loaded into 
process/interpreter by WSGIImportScript directive. 
No other way around it at this point.

Original comment by Graham.Dumpleton@gmail.com on 27 Jan 2010 at 11:40

• Added labels: Type-Other
• Removed labels: Type-Defect

[GoogleCodeExporter]

Can mod_wsgi do those imports itself (before loading the wsgi script)?

Original comment by ianbick...@gmail.com on 27 Jan 2010 at 11:42

[GoogleCodeExporter]

That is what the WSGIImportScript directive effectively provides you a way of 
doing, but pushing it onto the user to 
configure it to be done.

The problem is that mod_wsgi cant really know which ones should be imported. In 
Python 2.6 can find at least:

MacOS
_strptime
copy_reg
curses
itertools
resource
time
unicodedata
zlib

which are imported using that function.

Are other Python versions the same? How different are the names of the modules 
in Python 3.X given the 
renaming.

I would prefer not to end up with a list of modules different to each Python 
version that have to maintain.

Original comment by Graham.Dumpleton@gmail.com on 27 Jan 2010 at 11:53

[GoogleCodeExporter]

BTW, if you are using WSGIScriptAlias to mount WSGI application, provided you 
are using mod_wsgi 3.X, you can 
specific process group and interpreter/application group options to 
WSGIScriptAlias and it will preload script also. 
Eg.,

  WSGIScriptAlias /some/url /some/path/app.wsgi process-group=app1 application-group=%{GLOBAL}

This skips the need for WSGIImportScript.

This is dependent though on the WSGI application not lazily loading to the 
extent that the problem imports wouldn't 
get imported until a subsequent request arrives. If the latter, then you would 
be at risk of same thing happening 
under Python WSGI servers such as Paste and CherryPy WSGI servers.

Original comment by Graham.Dumpleton@gmail.com on 28 Jan 2010 at 12:01

[GoogleCodeExporter]

Ian Bicking in:

http://blog.ianbicking.org/2010/02/10/why-toppcloud-not-agnostic/

wants to think this is a mod_wsgi bug. If that is the case, why is it in any 
way sane that the following standalone 
Python script fails with the same problem.

import imp
import thread
import time

def run1():
   print 'acquire'
   imp.acquire_lock()
   time.sleep(5)
   imp.release_lock()
   print 'release'

thread.start_new_thread(run1, ())

time.sleep(2)

print 'strptime'
time.strptime("", "")
print 'exit'

The output of running this is

grumpy:~ grahamd$ python noblock.py 
acquire
strptime
Traceback (most recent call last):
  File "noblock.py", line 17, in <module>
    time.strptime("", "")
ImportError: Failed to import _strptime because the import lockis held by 
another thread.

It is just ridiculous that code executing in one thread could fail because at 
the time that it tries to call time.strptime() 
a different thread has the global import lock.

Note that this requires you be using Python 2.6.1 (I think) or later. I don't 
think this new function was in initial Python 
2.6 as from memory that is what is on Mac OS X Leopard and don't see problem 
there, but do on Mac OS X Snow 
Leopard, which is Python 2.6.1.

Original comment by Graham.Dumpleton@gmail.com on 10 Feb 2010 at 9:54

[GoogleCodeExporter]

The following is a discussion about this on comp.lang.python:

 http://www.mail-archive.com/python-list@python.org/msg248664.html

Christian, who seems may be the one who made the change that introduced this 
function, didn't seem to want to 
entertain that the fix may be a bad fix and that a better solution may need be 
found. That is, one has just 
replaced one run time failure with another runtime failure.

Original comment by Graham.Dumpleton@gmail.com on 9 Mar 2010 at 10:29

[GoogleCodeExporter]

Not that I am expecting for behaviour to be changed, have logged an issue 
(partly in protest) on Python bug 
tracker at:

http://bugs.python.org/issue8098

Marking this issue in mod_wsgi issue tracker as won't fix as have no desire to 
be adding endless work arounds 
for behaviour in Python or third party modules which is arguably broken.

Original comment by Graham.Dumpleton@gmail.com on 9 Mar 2010 at 10:49

• Changed state: WontFix