Problem reloading mx.DateTime in PyApache
Don't know if this should concern us in preparation for 2.0b1 release, but the following came across c.l.py this morning. FYI. Skip ------- start of forwarded message (RFC 934 encapsulation) ------- X-Digest: Python-list digest, Vol 1 #3344 - 13 msgs Message: 11 Newsgroups: comp.lang.python Organization: Concentric Internet Services Lines: 41 Message-ID: <39ABD9A1.A8ECDEC8@faxnet.com> NNTP-Posting-Host: 208.36.195.178 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Path: news!uunet!ffx.uu.net!newsfeed.mathworks.com!feeder.via.net!newshub2.rdc1.sfba.home.com!news.home.com!newsfeed.concentric.net!global-news-master Xref: news comp.lang.python:110026 Precedence: bulk List-Id: General discussion list for the Python programming language <python-list.python.org> From: Jon LaCour <jal@faxnet.com> Sender: python-list-admin@python.org To: python-list@python.org Subject: Python Problem - Important! Date: 29 Aug 2000 15:41:00 GMT Reply-To: jal@faxnet.com I am beginning development of a very large web application, and I would like to use Python (no, Zope is not an option). PyApache seems to be my best bet, but there is a MASSIVE problem with Python/PyApache that prevents it from being even marginally useful to me, and to most major software companies. My product requires database access, and the database module that I use for connecting depends on a library called mxDateTime. This is a very robust library that is in use all over our system (it has never given us problems). Yet, when I use PyApache to connect to a database, I have major issues. I have seen this same problem posted to this newsgroup and to the PyApache mailing list several times from over a year ago, and it appears to be unresolved. The essential problem is this: the second time a module is loaded, Python has cleaned up its dictionaries in its cleanup mechanism, and does not allow a re-init. With mxDateTime this gives an error: "TypeError: call of non-function (type None)" Essentially, this is a major problem in either the Python internals, or in PyApache. After tracing the previous discussions on this issue, it appears that this is a Python problem. I am very serious when I say that this problem *must* be resolved before Python can be taken seriously for use in web applications, especially when Zope is not an option. I require the use of Apache's security features, and several other Apache extensions. If anyone knows how to resolve this issue, or can even point out a way that I can resolve this *myself* I would love to hear it. This is the single stumbling block standing in the way of my company converting almost entirely to Python development, and I am hoping that python developers will take this bug and smash it quickly. Thanks in advance, please cc: all responses to my email address at jal@faxnet.com. Jonathan LaCour Developer, VertiSoft ------- end -------
skip wrote:
Don't know if this should concern us in preparation for 2.0b1 release, but the following came across c.l.py this morning.
http://sourceforge.net/bugs/?func=detailbug&bug_id=110601&group_id=5470 "The problem you describe is an artifact of the way mxDateTime tries to reuse the time.time() API available through the standard Python time module"
Essentially, this is a major problem in either the Python internals, or in PyApache.
ah, the art of debugging... </F>
Fredrik Lundh wrote:
skip wrote:
Don't know if this should concern us in preparation for 2.0b1 release, but the following came across c.l.py this morning.
http://sourceforge.net/bugs/?func=detailbug&bug_id=110601&group_id=5470
"The problem you describe is an artifact of the way mxDateTime tries to reuse the time.time() API available through the standard Python time module"
Here is a pre-release version of mx.DateTime which should fix the problem (the new release will use the top-level mx package -- it does contain a backward compatibility hack though): http://starship.python.net/~lemburg/mxDateTime-1.4.0-prerelease.zip Please let me know if it fixes your problem... I don't use PyApache. Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
Well, it appears that this version raises a different problem. Do I need to be running anything higher than python-1.5.2? Possibly this has something to do with how I installed this pre-release. I simply moved the old DateTime directory out of the site-packages directory, and then moved the mx, and DateTime directories from the zip that was provided into the site-packages directory, and restarted. Here is the traceback from the apache error log: patientSearchResults.py failed for 192.168.168.130, reason: the script raised an unhandled exception. Script's traceback follows: Traceback (innermost last): File "/home/httpd/html/py-bin/patientSearchResults.py", line 3, in ? import ODBC.Solid File "/usr/lib/python1.5/site-packages/ODBC/__init__.py", line 21, in ? import DateTime # mxDateTime package must be installed first ! File "/usr/lib/python1.5/site-packages/DateTime/__init__.py", line 17, in ? from mx.DateTime import * File "/usr/lib/python1.5/site-packages/mx/DateTime/__init__.py", line 20, in ? from DateTime import * File "/usr/lib/python1.5/site-packages/mx/DateTime/DateTime.py", line 8, in ? from mxDateTime import * File "/usr/lib/python1.5/site-packages/mx/DateTime/mxDateTime/__init__.py", line 12, in ? setnowapi(time.time) NameError: setnowapi On Tue, 29 Aug 2000, M.-A. Lemburg wrote:
Fredrik Lundh wrote:
skip wrote:
Don't know if this should concern us in preparation for 2.0b1 release, but the following came across c.l.py this morning.
http://sourceforge.net/bugs/?func=detailbug&bug_id=110601&group_id=5470
"The problem you describe is an artifact of the way mxDateTime tries to reuse the time.time() API available through the standard Python time module"
Here is a pre-release version of mx.DateTime which should fix the problem (the new release will use the top-level mx package -- it does contain a backward compatibility hack though):
http://starship.python.net/~lemburg/mxDateTime-1.4.0-prerelease.zip
Please let me know if it fixes your problem... I don't use PyApache.
Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
Jonathan LaCour wrote:
Well, it appears that this version raises a different problem. Do I need to be running anything higher than python-1.5.2? Possibly this has something to do with how I installed this pre-release. I simply moved the old DateTime directory out of the site-packages directory, and then moved the mx, and DateTime directories from the zip that was provided into the site-packages directory, and restarted. Here is the traceback from the apache error log:
patientSearchResults.py failed for 192.168.168.130, reason: the script raised an unhandled exception. Script's traceback follows: Traceback (innermost last): File "/home/httpd/html/py-bin/patientSearchResults.py", line 3, in ? import ODBC.Solid File "/usr/lib/python1.5/site-packages/ODBC/__init__.py", line 21, in ? import DateTime # mxDateTime package must be installed first ! File "/usr/lib/python1.5/site-packages/DateTime/__init__.py", line 17, in ? from mx.DateTime import * File "/usr/lib/python1.5/site-packages/mx/DateTime/__init__.py", line 20, in ? from DateTime import * File "/usr/lib/python1.5/site-packages/mx/DateTime/DateTime.py", line 8, in ? from mxDateTime import * File "/usr/lib/python1.5/site-packages/mx/DateTime/mxDateTime/__init__.py", line 12, in ? setnowapi(time.time) NameError: setnowapi
This API is new... could it be that you didn't recompile the mxDateTime C extension inside the package ?
On Tue, 29 Aug 2000, M.-A. Lemburg wrote:
Fredrik Lundh wrote:
skip wrote:
Don't know if this should concern us in preparation for 2.0b1 release, but the following came across c.l.py this morning.
http://sourceforge.net/bugs/?func=detailbug&bug_id=110601&group_id=5470
"The problem you describe is an artifact of the way mxDateTime tries to reuse the time.time() API available through the standard Python time module"
Here is a pre-release version of mx.DateTime which should fix the problem (the new release will use the top-level mx package -- it does contain a backward compatibility hack though):
http://starship.python.net/~lemburg/mxDateTime-1.4.0-prerelease.zip
Please let me know if it fixes your problem... I don't use PyApache.
Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
-- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
mal wrote:
Here is a pre-release version of mx.DateTime which should fix the problem (the new release will use the top-level mx package -- it does contain a backward compatibility hack though):
http://starship.python.net/~lemburg/mxDateTime-1.4.0-prerelease.zip
Please let me know if it fixes your problem... I don't use PyApache.
mal, can you update the bug database. this bug is still listed as an open bug in the python core... http://sourceforge.net/bugs/?func=detailbug&bug_id=110601&group_id=5470 </F>
Fredrik Lundh wrote:
mal wrote:
Here is a pre-release version of mx.DateTime which should fix the problem (the new release will use the top-level mx package -- it does contain a backward compatibility hack though):
http://starship.python.net/~lemburg/mxDateTime-1.4.0-prerelease.zip
Please let me know if it fixes your problem... I don't use PyApache.
mal, can you update the bug database. this bug is still listed as an open bug in the python core...
http://sourceforge.net/bugs/?func=detailbug&bug_id=110601&group_id=5470
Hmm, I thought I had already closed it... done. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
participants (4)
-
Fredrik Lundh -
Jonathan LaCour -
M.-A. Lemburg -
Skip Montanaro