stlib name clash when using python as ASP language

[Joost]

Hi guys, I have couple of simple python based active server pages
that make use of httplib2 which uses gzip.py. IIS, however, also has a
gzip.dll located at the iis/inetsrv path.

When using ASP the iis/inetsrv path is placed as the first item in
sys.path. Consequently importing httplib2 will cause the following
error:

import httplib2
File "c:\python24\lib\site-packages\httplib2-0.2.0-py2.4.egg
\httplib2\__init__.py", line 25, in ?
import gzip
ImportError: dynamic module does not define init function (initgzip)

This is, of course, because it tries to load the gzip.dll file instead
of the gzip.py file.

The following per page hack *fixes* the problem most of the time:
import sys
sys.path[0] = "c:/python24/lib"

Strangely, even with this code loaded in every page the import error
sporadically occurs. What would be the preferred way to solve this
name clash?

 

[Gabriel Genellina]

When using ASP the iis/inetsrv path is placed as the first item in
sys.path. Consequently importing httplib2 will cause the following
error:

ImportError: dynamic module does not define init function (initgzip)

The following per page hack *fixes* the problem most of the time:
import sys
sys.path[0] = "c:/python24/lib"

Strangely, even with this code loaded in every page the import error
sporadically occurs. What would be the preferred way to solve this
name clash?

You *assume* that [0] is the IIS path, but perhaps some other imported
module changed sys.path too, and now it's not the first one anymore.
If you know exactly the path, try sys.path.remove(iis_path).

 

[Joost]

You *assume* that [0] is the IIS path, but perhaps some other imported

module changed sys.path too, and now it's not the first one anymore.
If you know exactly the path, try sys.path.remove(iis_path).

It's was a hack and definitely not meant to go in to production
Since gzip.py lives in python24\lib I thought setting sys.path[0] to
python24\lib would load this load this module, no matter what.
However, in some magically way the sys.path gets modified during the
request by IIS. Maybe IIS resets the global sys.path per new request,
causing sporadic problems when request are handled concurrently? I
just don't know. The iis/inetsrv path is included in sys.path for a
reason and I don't want to fiddle around with sys.path to create
problems in other parts of the code. I was wandering if there is some
way to prevent a name clashes by using a custom importer or something
like that.

 

[Gabriel Genellina]

You *assume* that [0] is the IIS path, but perhaps some other imported
module changed sys.path too, and now it's not the first one anymore.
If you know exactly the path, try sys.path.remove(iis_path).

It's was a hack and definitely not meant to go in to production
Since gzip.py lives in python24\lib I thought setting sys.path[0] to
python24\lib would load this load this module, no matter what.
However, in some magically way the sys.path gets modified during the
request by IIS. Maybe IIS resets the global sys.path per new request,
causing sporadic problems when request are handled concurrently? I
just don't know. The iis/inetsrv path is included in sys.path for a
reason and I don't want to fiddle around with sys.path to create
problems in other parts of the code. I was wandering if there is some
way to prevent a name clashes by using a custom importer or something
like that.

Python 2.5 has absolute and relative imports, that should handle such
problems in the future.
But in your case I can think of:
- *prepend* python24\lib instead of replacing index 0: sys.path.insert(0,
python24\lib)
- copy gzip.py to another, empty directory, and put *that* directory in
front of sys.path
- play with ihooks.py