ImportError: No module named _strptime

[Gnarlodious]

While debugging a minor problem I ran into the same error message I reported previously:

ImportError: No module named _strptime

My devbox setup looks like this:

Apache/2.2.22, mod_wsgi/3.4, Python/3.2.3

However the error does not occur on my server, which is running setup:

Apache/2.2.22, mod_wsgi/3.3 Python/3.1.3

This error only occurs under mod_wsgi. I can run the single-page script and the webapp with no error. Only when it is running under mod_wsgi does the error occur.

Oddly enough, all other module time functions seem to work as expected.

-- Gnarlie

[Graham Dumpleton]

FWIW. They fixed it in Python 3.3.

http://bugs.python.org/issue8098

Because it relates to thread locking, all depends on what order things run and when.

Graham

--
You received this message because you are subscribed to the Google Groups "modwsgi" group.
To view this discussion on the web visit https://groups.google.com/d/msg/modwsgi/-/z_RV9TjHoBwJ.
To post to this group, send email to mod...@googlegroups.com.
To unsubscribe from this group, send email to modwsgi+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.

[Gnarlodious]

That didn't fix it.

-- Gnarlie

[Graham Dumpleton]

Are you sure your code is running under Python 3.3 with your mod_wsgi? Print out value of sys.version to check.

When I try the test case on that bug report (updated to Python 3 syntax) and run it on Python 3.3 it works fine.

Graham

To view this discussion on the web visit https://groups.google.com/d/msg/modwsgi/-/kfthoSKomYwJ.

[Gnarlodious]

I also attempted to load the "threading" module like it did in Py 3.2 but the error returned.

The webapp says this, maybe you can spot a config problem:

SERVER_SOFTWARE Apache/2.2.22 (Unix) mod_wsgi/3.4 Python/3.3.0 DAV/2
mod_wsgi.application_group Sectrum.dev|/wsgi.wsgi
mod_wsgi.callable_object application
mod_wsgi.enable_sendfile 0
mod_wsgi.handler_script
mod_wsgi.input_chunked 0
mod_wsgi.listener_host
mod_wsgi.listener_port 80
mod_wsgi.process_group Sectrum
mod_wsgi.queue_start 1353929621096826
mod_wsgi.request_handler wsgi-script
mod_wsgi.script_reloading 1
mod_wsgi.version (3, 4)
wsgi.errors <_io.TextIOWrapper encoding='utf-8'>
wsgi.file_wrapper
wsgi.input
wsgi.multiprocess True
wsgi.multithread False
wsgi.run_once False
wsgi.url_scheme http
wsgi.version (1, 0)

[Graham Dumpleton]

If you use the following hello world does it fail or work.

import imp

import _thread

import time

def application(environ, start_response):

    status = '200 OK'

    output = b'Hello World!'

    import os

    output = str(os.environ).encode('UTF-8')

    response_headers = [('Content-type', 'text/plain'),

                        ('Content-Length', str(len(output)))]

    start_response(status, response_headers)

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

    return [output]

--

You received this message because you are subscribed to the Google Groups "modwsgi" group.

To view this discussion on the web visit https://groups.google.com/d/msg/modwsgi/-/wQv6wENayyAJ.

[Gnarlodious]

When running under the default 10.8.2 Server.app mod_wsgi configuration, the script outputs in the browser plain text:

environ({'SERVER_INSTALL_PATH_PREFIX': '/Applications/Server.app/Contents/ServerRoot', 'XPC_SERVICES_UNAVAILABLE': '1', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', '__CF_USER_TEXT_ENCODING': '0x0:0:0'})

error.log reports:

[Tue Nov 27 05:42:16 2012] [error] acquire

[Tue Nov 27 05:42:18 2012] [error] strptime

[Tue Nov 27 05:42:21 2012] [error] release

[Tue Nov 27 05:42:21 2012] [error] exit

The same results occur under my webapp config as listed previously.

I should mention that my mod_wsgi is custom-built for daemon mode while the Apple supplied mod_wsgi is built for embedded mode. Not sure if it matters.

-- Gnarlie

[Graham Dumpleton]

That is the test case that triggered the original known problem. That the test works okay suggests you are having a different problem. You will need to provide more information such as actual Python traceback and if possible a small example that replicates the problem reasonably reliably.

Graham

--

You received this message because you are subscribed to the Google Groups "modwsgi" group.

To view this discussion on the web visit https://groups.google.com/d/msg/modwsgi/-/3viHuw2SywAJ.

[Gnarlodious]

Thanks for that tip, the problem is fixed somehow. I did spend several days rewriting my scripts to get tighter control over imported modules but exactly what part of the rewrite did the trick I don't know. But I didn't change anything in my *.wsgi script so it must be in Python. As more people adopt Python 3.3.0 it may get easier to figure out what is going on.

-- Gnarlie

[Gnarlodious]

I was able to zero in on the cause of the problem, sort of. I inadvertently fixed the problem by importing my Gnomon module in my *.wsgi script, just like with the other two Python modules that errored. I am not sure what is so special about my Gnomon module that causes the error, except that in it that I overrode the time module by saying

import time as Pytime

This because I need to use "time" as the name of a query string variable name. This looks like the cause of mod_wsgi's inability to find Pytime. Importing Gnomon in *.wsgi somehow enables the webapp to know where Pytime._strptime is located. Note the underscore before the name, I don't know what the signficance of that is. In any case, this problem only occurs inside mod_wsgi. The script runs normally in single-shot mode, and also interactively.

This evidently is a feature of Python 3.3.0. Or possibly a bug.

-- Gnarlie

[Graham Dumpleton]

If you can manage to get it down to a small example then we can verify it and if need be lodge it as a Python bug report. They may well have missed some corner case.

Graham

-- Gnarlie

--

You received this message because you are subscribed to the Google Groups "modwsgi" group.

To view this discussion on the web visit https://groups.google.com/d/msg/modwsgi/-/s7P3ZMrFghAJ.

[Gnarlodious]

To fix this, I had to add

import _strptime

to my *.wsgi script. This apparently is somehow related to threadlocking.

Unanswered questions, which the comp.lang.python group roundly riidiculed me for asking:

1) Why is the only error reported a cryptic "AttributeError: 'module' object has no attribute '_strptime' "?

2) Why is it time.time() functions normally while time.strptime() errors?

3) Why does this error occur in mod_wsgi and not interactive mode?

After this mess, I am not sure Python handles threaded processing very robustly. It seems like an embarrassing problem Python people prefer to not discuss. Let the user beware, Python 3.1.3 seems to be the last version where threadlocking is not drastically enforced.

-- Gnarlie

[Graham Dumpleton]

The relevant bug reports you want to read and obviously educate the comp.lang.python people about are:

http://bugs.python.org/issue8098

http://bugs.python.org/issue9260

It is a sad fact that on many Python related forums there is a growing number of people who think they know stuff and actually know crap all.

All the problems derive from a stupid function in Python internals called PyImport_ImportModuleNoBlock(). It was designed to avoid lockups of the import machinery but just causes other problems because a module import can fail if the import lock is held by a different thread. This faulty magic fairy dust was sprinkled on the time.strptime() function which internally loads _strptime module. If you access time.strptime() when another thread holds the import lock, the call will fail because of a failed import. All very silly.

Graham

--

You received this message because you are subscribed to the Google Groups "modwsgi" group.

To view this discussion on the web visit https://groups.google.com/d/msg/modwsgi/-/Pj8lEds7Q4cJ.