Python + Win32ALL + ASP = Problems accessing Request/Response/Session/Application objects

Joe Salmeri JoeSalmeri at comcast.net
Mon Jul 29 09:55:07 EDT 2002


Thanks Mark!

I'll use the ax object, one parm is better than having to pass each of the
objects in a separate parm, plus that way they are all available even if I
originally only need one of them.


"Mark Hammond" <mhammond at skippinet.com.au> wrote in message
news:3D3F8DF3.9060807 at skippinet.com.au...
> Joe Salmeri wrote:
>
> > Hopefully Mark Hammond will see this, I'm sure he will be able to
provide
> > the answer (he always does!)
>
> OK :)
>
> It is all a bit nasty I'm afraid.  In a nutshell, these objects are just
> COM objects that exist in some global namespace.  (They are actually
> pyscript.ScriptItem objects, added as globals in
> pyscript.PyScript.RegisterNamedItem())
>
> Each "engine" has a global namespace.  The "engine" is defined by the
> application (ie, ASP), and "named items" along with the user specified
> "script code" are added to this engine.
>
> ASP obviously could have many Python engines open at once - one for
> every different connection to a page with Python content.  Your external
> module may be used by any number of other ASP connection/scripts, so you
> really can't consider these script objects as "global" in any sense of
> the word.
>
> So while you may be able to devise a scheme for yourself, there really
> isn't much the ActiveScripting framework can do to help - nothing here
> is "global", so nothing is exposed as such.
>
> You could just pass the "ax" object around - it should have all the
> globals as attributes - eg, "ax.session" may work.
>
> Mark.
>





More information about the Python-list mailing list