ideal architecture for Python/IIS/ASP/COM?

[Bill Seitz]

We're going to be building a number of intranet/extranet server 
applications. Since the users will be spending a lot of their time in 
Microsoft client apps (Word, Outlook), it seems logical to develop 
the server side on a Microsoft platform: Win2K, Active Directory, 
Exchange, IIS, etc. to get the integrated security model and ease of 
bolting on various side services (like FTP, WebDAV, etc.).

But, having lived through the maintenance lifecycle of ColdFusion and 
other semi-structured languages, I'd rather develop in Python than VB 
or anything else.

I've gotten Python working with my IIS server for doing simple ASP 
stuff.

But I'd like to plan on this stuff staying fairly manageable over 
time. So I'd like the bulk of my logic implemented in python modules 
rather than ASP pages. What's the best way to manage this? Have the 
browser ask for an ASP page, which calls Python methods? Call a .py 
file which then calls an ASP to deliver its output (not sure if this 
is even possible)? Something else? Is there any reason for me to turn 
my Python code into COM objects?

Many apps I build will use SqlServer as a db. Should I use the ADO 
COM objects, mxODBC, or something else?

I anticipate that, down the road, I'll be buying some larger packaged 
apps (like an industry-targeted accounting system) which exposes a 
COM API. Does the need to access this API (maybe to build a web 
interface when the original app uses a fat client) change the 
preferred architecture?