Python and ASP Observations

[Eugene Goodrich]

I do a lot of ASP coding, so I'm getting to really hate VBScript for
all the features it doesn't have.  Since Python is so great
(especially compared to VBScript) and I like it so much, an obvious
improvement to my obsessive situation is to code ASP in Python
instead.

Aside from the initial stumbling blocks (1: I spaced on the most
likely capitalization of the Request and Response objects; 2: Must use
.SetValue on Session / Application objects), things are going well,
but there are quirks at every turn.

I haven't seen all my questions answered or my observations already
observed in the newsgroup.  (To be fair, I've only done a bit of
DejaNews searching, and I have only recently begun to keep up with the
news.)  Anyway, working from these assumptions, I figured I'd post
some of what I found using Python for ASP in case anyone else would
like to go that way.

My config: Wint NT 4.0 SP 4 or so (you can't say "no" to SPs forever),
IIS 4, Python 1.52, and Win32whatever to match.

Simple stuff:  
  * the "5 magic objects" in ASP are all English-capitalized.  But you
knew that.
  * to stick stuff into the Session and Application objects, you need
to use Session/Application.SetValue (key, value).  You also knew that;
I read it in this newsgroup.

Quirks:
  * You can store lists in the Session and Application objects, but
when you retrieve them, they come back as tuples.
  * You can't store dictionaries directly in the Session / Application
objects.  But you can convert them to strings first, and eval them
when you retrieve them to inflate them back into dictionaries.
  * I've read that some people have had trouble putting references to
COM objects into the Session / Application objects.  (The example I
saw used the fileSystemObject, but for me the applicable object would
definitely be the ADO Connection object.)  Well, if you put the COM
object reference in a list, then you can put it into the Session /
Application object no problem.  When you retrieve your reference,
everything appears to work hunky-dory.  I've tried it with the
Application and Session objects using the ADO Connection and Recordset
objects while they were "in operation," and they worked fine.  I
should point out, however, that I generated my references using ASP's
Server.CreateObject (sProdID), not win32com.client.Dispatch ().
  * You can't store python object instances in the Session /
Application objects, not even if they're wrapped in lists.  This
behavior probably explains the problem with dictionaries, and also
probably why lists get converted to tuples, but since I'm not an
expert on the internals, I couldn't say for sure.

For my ASP style, being able to persist the connection object(s) and a
cache of commonly used database tables (e.g. the table where I store
all my queries :) is a must.  Plus, I like to do my own recordset
pooling.  For some time I had been disappointed that Python didn't
play well enough with ASP to do what I required.  So far, though, it
looks like it's just going to take doing things a little differently.
The benefits of Python over <shudder> VBScript still vastly outweigh
the costs of the tricky bits.

      -Eugene
import binascii; print binascii.a2b_base64 ('ZXVnZW5lQGlzb21lZGlhLmNvbQ==')