Python + IIS/ASP questions (modules, namespaces, etc)

[Preston Landers]

Mark Hammond <mhammond at skippinet.com.au> wrote in message news:<afaM9.2627$W51.6043 at news-server.bigpond.net.au>...

> Preston Landers wrote:
> > Perhaps I should post this on the Active Python mailing list, as that
> > seems to be more win32 oriented.
> 
> I don't read that list though <wink>

I'm afraid I can't tell if you're being sarcastic or not. 

> You should be able to make things work.  The quoted posting is missing 
> the detail that __ax_main__ is never put into sys.modules - thus there 
> is no real problem with sharing that name.  Unfortunately the poster of 
> that article didn't take into account the observation that it *does* 
> work, despite his analysis to the contrary.
> 
> You can cache any *Python* object you like in the Python ASP engine. 
> Python will refuse to unload even when asked to by IIS, so global state 
> will never go away.  Normal Python modules imported by ASP pages will 
> only be imported once, as per normal Python.

What about if for whatever reason we DO need to reset the Python ASP
engine?  Is the only way to do that to re-register it?  

I understand what you are saying about __ax_main__ (I think) -- but I
still do not understand whether each client/session/whatever gets its
own unique copy of each module that it needs.  This is what our
application currently requires, because for better or worse, many bits
of important state are kept as module variables or class variables, as
opposed to instance variables.  It is unrealistic for us to consider
changing that now.

My current understanding is that the Python ASP engine does keep a
single instance in memory of each module -- and sessions which
manipulate module variables are likely to step on each others toes.

If that is NOT true, we will probably be ok.  However, if it is the
case, then we can probably still use ASP -- except will we just use a
simple bit of code that essentially just contacts one of the
standalone application servers and pulls the response down.  This will
avoid the overhead of spawning the python.exe just to run an
equivalent small script that in turn contacts an application server
for the real work.

Thanks for the response.

Preston Landers