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

Pythoneers:

I have some technical questions about the python ASP server side
scripting available to IIS users.  I've seen someone post some
questions along the same lines as the questions I have (one is quoted
below), but unfortunately I have not seen any relevant responses.
Perhaps I should post this on the Active Python mailing list, as that
seems to be more win32 oriented.

Basically I have my web site, which is 100% dynamically generated in
Python.  On Unix we have Apache and mod_python, which works
beautifully.  Each Apache child process has a Python interpreter which
is re-used for each request.  Each interpreter has a namespace which
persists between requests, which allows us to stash a database
connection that can be reused.  Yet, each interpreter remains in a
separate process, so there are no issues with stepping on each others
modules, or threading issues with the global lock.  This works well
and we are happy with it, and we want to achieve a similar effect on
the Windows platform.

Currently, our Windows code works as a traditional CGI (spawning a
python.exe for each request from IIS.)  To avoid the significant
overhead of acquiring a new database connection for each request, the
CGI script ends up talking (over a socket) to a limited number of
pre-initialized "application server" processes that do the actual
work.  This works OK for limited numbers of users, but as you might
imagine it does not scale very well as you pile on the users.

The obvious solution would be to just use Apache and mod_python on
Windows, since we know our solution works there and we are happy with
it.  And this may indeed be the best way to go -- I am going to look
into the feasibility of building and packaging Win32 Apache+mod_python
for our platform.  But, for one reason or another, the powers that be
have indicated that we are to support IIS on Windows.

So, I have been examining the Python active server pages (ASP)
solution.  It seems that ASP is the only way to get state (such as a
DB connection) to persist across connections.  However, there appear
to be issues with modules being shared (as in the quoted message
below.)  All of our application modules were basically written under
the assumption that they would not be shared, and we use a number of
module-level variables, etc.  I am also worried about bugs in our code
crashing the whole site on a regular basis.  I've got a copy of
O'Reilly's "Python Programming on Win32" but the section on ASP is
woefully lacking in details like these.

The only real state I need to persist across connections is the actual
database connection object, since these can be so expensive to obtain
(about 3 or 4 seconds in my tests.)

The idea I had for that was to register a RemoteServer COM object that
would basically act as a database connection pool.  Each web request
would be spawned as a traditional CGI (I'm not terribly worried about
the overhead there) -- and it would then talk to the COM object and
send all of its database methods as packaged requests to it, and
receive database rows (etc) in return.  All of the DB connections
would be kept inside the RemoteServer COM object.

The only drawback there (besides the work required to code up the
database pool COM object) is that we now have to worry about correctly
translating parameter (and exception) types across COM, which also
uses Unicode for all strings.  Sounds like a lot of headache just to
be able to keep a reusable database connection.  Hopefully calling
Python COM objects from Python clients should take care of most of the
{*filter*}details, but I haven't tried it yet.  The most complicated
objects we will be passing will likely be lists of tuples with varying
simple types inside (ie, database record sets.)

Basically I'm writing this post to find out what other people may have
done in this area and to ask for general guidance, etc.  Has anyone
tried using ASP or a separate COM server for the sole purpose of
database connection pooling?

I'm also going to try to find out more about the Apache + mod_python
on win32 route, and whether that is "politically" feasible for us.
Has anyone else out there had much experience with mod_python on
win32?

Any suggestions or comments will be greatly appreciated and hopefully
beneficial for other people out there who want to deploy high volume
dynamic web sites on Windows with Our Favorite Language.

yours,

Preston Landers
Senior Software Developer
Journyx, Inc.

pibble at yahoo dot com  (or)
planders at journyx dot com

------------------------------------------------------------------

Quoted posting from "chris" below (no email address given, posted Nov
20th 1998 in c.l.python.)

Follow my thought process for a moment:

As I understand the Python ASP implementation, the Python ActiveX scripting
engine is loaded by IIS on the first ASP invocation.  That engine continues
to run and stay loaded from that point forward to handle each Python ASP
request.  (IIS may unload it at some point, but it won't affect this
discussion.)

The engine (which occupies high-level and separate namespaces including
__main__) receives each ASP file from IIS, sets it up in it's own module
(and namespace) __ax_main__ (below __main__) and puts the ASP objects
(Request, Response, etc..) in the namespace for that script.  Each ASP
script can then execute and act upon the ASP objects in its namespace.  Each
ASP script/file that executes, get's its own namespace and its own separate
ASP objects to act upon.  The Python engine runs continuously above all the
ASP file invocations and manages all the requests, executions, and ASP
objects.

Furthermore:

I have verified that a single ASP file, while excuting, is run in a module
called __ax_main__ (as mentioned above).  If my previous understandings are
correct, then it would seem that subsequent ASP executions while the first
is still running CAN'T receive the same module name.  Perhaps the namespaces
for each subsequent concurrent module are __ax_main1__, __ax_main2__ ????  I
don't see how they could have the same name if all the ASP executions are
occuring in the same Python engine.  Comments?

--------------

On a related topic, it would follow that each IMPORT statement in all the
ASP files (that may be running concurrently) are all importing into the same
Python engine.  Therefore, two ASP files (running concurrently by
IIS/Python) that both perform "import foo.py" are using the same module AT
THE SAME TIME (classes generally don't count in this discussion - I'm
assuming they are safe).

In a "regular" Python program (if I don't use ASP - just standard
command-line) the multiple import issue is not a problem because the Python
command-line configuration is single-threaded.  A non-ASP Python program can
have multiple modules all importing and using each other because there is
only one thread.  The multiple uses of a module can't collide.

Now, my next assumption is that the Python ASP engine is multi-threaded.  It
would seem to be a poor implementation otherwise.  With this assumption
(multi-threaded, not a poor-implementation :-), is the multiple use of
imported modules a problem and does the engine perform any actions to
guarantee thread-safe behavior?  In the example above, what do

An example:

foo.py
=============
count=0

def getCurrentCount():
    count=count+1
    return count
=============

Assume many different ASP files with code such as:

import foo
Response.write(getCurrentCount())

What behavior do the ASP files show?  Is is deterministic?  Does each ASP
file always return 1.  Do they increment until all ASP files are finished
running and then reset back to 1?

chris



Mon, 06 Jun 2005 01:38:03 GMT  
 Python + IIS/ASP questions (modules, namespaces, etc)

Quote:

> Any suggestions or comments will be greatly appreciated and hopefully
> beneficial for other people out there who want to deploy high volume
> dynamic web sites on Windows with Our Favorite Language.

Sounds like you're basically forced to use IIS.  You could consider using
Webware, which provides a persistent threaded application server (WebKit)
and also provides a CGI adapter written in fast C code (wkcgi.exe) that
communicates with the app server using a socket.

You still incur the CGI process-starting overhead on every request, but at
least it's a lightweight C program rather than a larger Python process.

See http://webware.sourceforge.net for details.

- Geoff



Mon, 06 Jun 2005 01:56:56 GMT  
 Python + IIS/ASP questions (modules, namespaces, etc)


Quote:
> Pythoneers:

> I have some technical questions about the Python ASP server side
> scripting available to IIS users.  I've seen someone post some
> questions along the same lines as the questions I have (one is quoted
> below), but unfortunately I have not seen any relevant responses.
> Perhaps I should post this on the Active Python mailing list, as that
> seems to be more win32 oriented.

> <snip>

> Currently, our Windows code works as a traditional CGI (spawning a
> python.exe for each request from IIS.)  To avoid the significant
> overhead of acquiring a new database connection for each request, the
> CGI script ends up talking (over a socket) to a limited number of
> pre-initialized "application server" processes that do the actual
> work.  This works OK for limited numbers of users, but as you might
> imagine it does not scale very well as you pile on the users.

My guess is that a single use COM server could keep track of the number of
connections and start up a new server when some threshold is reached.  I
think this is the way to do it.

Quote:
> The obvious solution would be to just use Apache and mod_python on
> Windows, since we know our solution works there and we are happy with
> it.  And this may indeed be the best way to go -- I am going to look
> into the feasibility of building and packaging Win32 Apache+mod_python
> for our platform.  But, for one reason or another, the powers that be
> have indicated that we are to support IIS on Windows.

Is there any reason to not use both?  Run IIS on port 80 and Apache on 8000
and redirect traffic there when Python is involved.  If it has to be a
secret, have IIS make requests to the Apache server and and just reprint the
outcome :-)  all of the .asp pages would look like

import urllib
u = urllib.urlopen('http://my-apache-server:8000/' +
str(Request.QueryString('page')))
Response.Write(u.readlines())

Obviously this is a dumb solution, but maybe no dumber on insisting on IIS.

Quote:
> <snip>

> The only real state I need to persist across connections is the actual
> database connection object, since these can be so expensive to obtain
> (about 3 or 4 seconds in my tests.)

That seems slow, even for win32.  On my win2k server, Python can create
literally hundreds of ADO connection objects (to an Access db!) in that much
time.

Quote:
> The idea I had for that was to register a RemoteServer COM object that
> would basically act as a database connection pool.  Each web request
> would be spawned as a traditional CGI (I'm not terribly worried about
> the overhead there) -- and it would then talk to the COM object and
> send all of its database methods as packaged requests to it, and
> receive database rows (etc) in return.  All of the DB connections
> would be kept inside the RemoteServer COM object.

> The only drawback there (besides the work required to code up the
> database pool COM object) is that we now have to worry about correctly
> translating parameter (and exception) types across COM, which also
> uses Unicode for all strings.  Sounds like a lot of headache just to
> be able to keep a reusable database connection.

You might look to ISAPI as a way to do this.  Most notes I have seen re
Python and ISAPI have said that if you are using Python in the first place
that the performance gains you might see would be lost, so ASP is generally
an easier way to go, but in your case it may be different.  My guess is that
an ISAPI interface will require C++/Delphi/VB or some such thing though.

Quote:
> Hopefully calling
> Python COM objects from Python clients should take care of most of the
>{*filter*}details, but I haven't tried it yet.

Probably not.  Python COM objects are very difficult to use as single use
COM servers. You might be better writing a Single use COM server in VB to
hold the db connection and use it from Python.  OTOH, maybe there is some
namespace stuff you could take advantage of by having the COM server import
a Python module with Global variables that will persist across all instances
(I actually think this will not work, but I am looking for someone to
explain why -- probably because each instance of a Python CO object tarts up
an instance of the interpreter).

Quote:
> The most complicated
> objects we will be passing will likely be lists of tuples with varying
> simple types inside (ie, database record sets.)

watch out for tuples and COM ... use lists.

Quote:
> Basically I'm writing this post to find out what other people may have
> done in this area and to ask for general guidance, etc.  Has anyone
> tried using ASP or a separate COM server for the sole purpose of
> database connection pooling?

> <snip>

That's my $0.02

-doug



Mon, 06 Jun 2005 04:36:06 GMT  
 Python + IIS/ASP questions (modules, namespaces, etc)
Quote:
> > <snip>

> > The only real state I need to persist across connections is the actual
> > database connection object, since these can be so expensive to obtain
> > (about 3 or 4 seconds in my tests.)

> That seems slow, even for win32.  On my win2k server, Python can create
> literally hundreds of ADO connection objects (to an Access db!) in that much
> time.

I agree, something is amiss with your connection object, and it's not
something I'd try to persist. I open ADO connections to SQL Server on
a win2k server with Python/win32com and I've never had problems with
performance... and I often use the "implied connection" of opening ADO
recordsets with the connection string as a parameter so I do create
and drop a lot of connections.


Mon, 06 Jun 2005 06:27:56 GMT  
 Python + IIS/ASP questions (modules, namespaces, etc)

Quote:

> My guess is that a single use COM server could keep track of the number of
> connections and start up a new server when some threshold is reached.  I
> think this is the way to do it.

This is actually not a bad idea -- however it is complicated by some
details that I did not mention in my original posting.

We had already thought of a solution like this, but we have inherited
a fairly broken design for a caching layer in these application
servers.

Basically, each app server maintains a socket connection to *every
other* app server for the sole purpose of sending brief "clear caches
for table X" messages to each other.  That means the total number of
interconnections required grows exponentially as the number of app
servers increases linearly.  Yeah, I know, it's ridiculous.

We discussed ripping that design out and basically making a
centralized cache process, so that each app server only has to talk to
1 process (though there might be a backup process or two.)  

When we discussed that, we basically ruled it out for the time being
due to the complexity involved in the redesign of the caching logic.
However, the more I look at our options here, the more I see that this
appears to be really the least complicated solution in some respects.

If we went that route, we could probably cut out the CGI script
overhead (spawning python.exe) and just have a snippet of ASP-safe
code directly contact an app server.

Quote:
> > The obvious solution would be to just use Apache and mod_python on
> > Windows, since we know our solution works there and we are happy with
> > it.  And this may indeed be the best way to go -- I am going to look
> > into the feasibility of building and packaging Win32 Apache+mod_python
> > for our platform.  But, for one reason or another, the powers that be
> > have indicated that we are to support IIS on Windows.

> Is there any reason to not use both?  Run IIS on port 80 and Apache on 8000
> and redirect traffic there when Python is involved.  If it has to be a
> secret, have IIS make requests to the Apache server and and just reprint the
> outcome :-)  
<snip>
> Obviously this is a dumb solution, but maybe no dumber on insisting on IIS.

Right -- we could use Apache anyway, and have a passthrough from IIS.
I'm sure there's a faster way to do the passthrough than with Python.
I'm fairly confident that if we can demonstrate a stable, widely
usable mod_python/win32 build, then we will be able to use it (no
secrecy required ;-))

I am going to be spending some time in the near future trying to get a
build of mod_python for win32.

Quote:
> > The only real state I need to persist across connections is the actual
> > database connection object, since these can be so expensive to obtain
> > (about 3 or 4 seconds in my tests.)

> That seems slow, even for win32.  On my win2k server, Python can create
> literally hundreds of ADO connection objects (to an Access db!) in that much
> time.

We're talking about ODBC connections to MS Sql Server and/or Oracle
here.  The slowdowns appear to be in either ODBC itself or the
Python/ODBC layer (which has given us a number of headaches and
stability problems in general ...)  We're using the odbc.pyd module
that
comes with Python 2.1.1.

Quote:

> You might look to ISAPI as a way to do this.  Most notes I have seen re
> Python and ISAPI have said that if you are using Python in the first place
> that the performance gains you might see would be lost, so ASP is generally
> an easier way to go, but in your case it may be different.  My guess is that
> an ISAPI interface will require C++/Delphi/VB or some such thing though.

We've also considered an ISAPI dll -- and decided that we did not have
the expertise (or the budget) to do a proper job of this in-house.
Ultimately, this would probably provide the fastest performance with
the most flexibility, but would require lots of up-front development
(plus tie us to IIS even more than we are.)

Quote:
> > The most complicated
> > objects we will be passing will likely be lists of tuples with varying
> > simple types inside (ie, database record sets.)

> watch out for tuples and COM ... use lists.

That's a little scary.  Any particular reason why?  

I suppose we can just pass the list around and then do a "rec =
tuple(rec)" thing when we get the recordset back (because our code is
expecting tuples in some cases.)

thanks for the input!

yours,
Preston Landers



Mon, 06 Jun 2005 07:36:54 GMT  
 Python + IIS/ASP questions (modules, namespaces, etc)



Quote:

> > My guess is that a single use COM server could keep track of the number
of
> > connections and start up a new server when some threshold is reached.  I
> > think this is the way to do it.

> This is actually not a bad idea -- however it is complicated by some
> details that I did not mention in my original posting.

> We had already thought of a solution like this, but we have inherited
> a fairly broken design for a caching layer in these application
> servers.

> Basically, each app server maintains a socket connection to *every
> other* app server for the sole purpose of sending brief "clear caches
> for table X" messages to each other.  That means the total number of
> interconnections required grows exponentially as the number of app
> servers increases linearly.  Yeah, I know, it's ridiculous.

I am not sure I understand this at all, but it sounds like you have created
a workgroup with a hub when what you want is a hub and spoke server
client/system with a switch.  very odd.

Quote:
> We discussed ripping that design out and basically making a
> centralized cache process, so that each app server only has to talk to
> 1 process (though there might be a backup process or two.)

With a couple of processors and a well written threaded COM server (or maybe
something along the lines of how Medusa is designed to avoid threads) this
seems like a reasonable idea.

<snip>

- Show quoted text -

Quote:
> > > The only real state I need to persist across connections is the actual
> > > database connection object, since these can be so expensive to obtain
> > > (about 3 or 4 seconds in my tests.)

> > That seems slow, even for win32.  On my win2k server, Python can create
> > literally hundreds of ADO connection objects (to an Access db!) in that
much
> > time.

> We're talking about ODBC connections to MS Sql Server and/or Oracle
> here.  The slowdowns appear to be in either ODBC itself or the
> Python/ODBC layer (which has given us a number of headaches and
> stability problems in general ...)  We're using the odbc.pyd module
> that
> comes with Python 2.1.1.

I don't know much about ODBC from Python, but ADO can use ODBC, and if you
are on win32 it might not be a bad idea.  From the notes above, it sounds
like the bottleneck could be elsewhere and just happens to be visible while
making the db connections.

Quote:
> > > The most complicated
> > > objects we will be passing will likely be lists of tuples with varying
> > > simple types inside (ie, database record sets.)

> > watch out for tuples and COM ... use lists.

> That's a little scary.  Any particular reason why?

Search Google for the full answer, but when Python COM servers return tuples
to VB clients, the clients can't understand the data.  Lists, however, come
back as variant arrays. Mark Hammond has posted the reason for this, but I
don't remember it.

-d



Mon, 06 Jun 2005 11:29:56 GMT  
 Python + IIS/ASP questions (modules, namespaces, etc)

Quote:

> Pythoneers:

> I have some technical questions about the Python ASP server side
> scripting available to IIS users.  I've seen someone post some
> questions along the same lines as the questions I have (one is quoted
> below), but unfortunately I have not seen any relevant responses.
> 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>

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.

There is an issue caching COM objects, and particularly COM objects
passed by, or created by IIS itself.  In this case you can still keep a
global reference, but any attempts to later use the object will result
in failure.  But caching Python objects is no problem.

Also, IIS has a "global.asa" concept that can be used explicitly to
share global state.  I've never used it though (but I hear it works fine
with Python!)

But from what you described, you don't actually need IIS Response or
Session objects or functionality, so it should work fine.

Mark.



Mon, 06 Jun 2005 10:34:46 GMT  
 Python + IIS/ASP questions (modules, namespaces, etc)

Quote:


> > 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.

Quote:
> 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



Tue, 07 Jun 2005 03:02:54 GMT  
 Python + IIS/ASP questions (modules, namespaces, etc)

Quote:

> I am not sure I understand this at all, but it sounds like you have created
> a workgroup with a hub when what you want is a hub and spoke server
> client/system with a switch.  very odd.

I suppose that is one way to look at it.  Yes, the design that I
inherited is very odd.  I'm not exactly fond of it.  I do believe that
we may focus turning it into a "hub/spoke" model.

Quote:

> > We discussed ripping that design out and basically making a
> > centralized cache process, so that each app server only has to talk to
> > 1 process (though there might be a backup process or two.)

> With a couple of processors and a well written threaded COM server (or maybe
> something along the lines of how Medusa is designed to avoid threads) this
> seems like a reasonable idea.

Rather than using COM (since we would probably want to use the design
on Unix as well) I was thinking just a simple select() based process
that served as a clearinghouse for the 'clear cache' and other such
messages.  When and if we determined that it was a bottleneck we could
rewrite it in C.

Quote:
> > > That seems slow, even for win32.  On my win2k server, Python can create
> > > literally hundreds of ADO connection objects (to an Access db!) in that
>  much
> > > time.

Yeah, it's absurdly slow.  It's slow when creating the very first
connection in the life of the process, but subsequent connections are
fairly fast.  However, for our purposes (CGI) each request will
essentially be a new process, so we still have the delay.

Just now I did a few simple tests playing around with ADO.  It does
look like ADO is definitely the way to go here.

On my test system (PIII 600 mhz w/ Windows XP + SQL Server 2000) -- it
takes usually around 2.2 seconds on average to create the first ODBC
based connection.  However, the same ADO connection only takes about
0.12 seconds the first time (and less subsequently.)

So, now I am going to look at converting our Windows database code to
using an ADO based module.  One weird thing is that the
RecordSet.GetRows function returns stuff in a weird (Columns, Rows)
format, instead of the (Rows, Columns) that we need.  My first pass at
a python function to transform that is disappointingly slow.

I am also concerned about the proliferation of ADO library versions
out there.  Our product supports Windows NT4 (Service Pack 6) through
XP -- and we'd prefer not to have to redistribute any libraries.
Right now I'm playing around with ADO 2.5, though I think they're up
to at least 2.7 now.

Quote:
> Search Google for the full answer, but when Python COM servers return tuples
> to VB clients, the clients can't understand the data.  Lists, however, come
> back as variant arrays. Mark Hammond has posted the reason for this, but I
> don't remember it.

OK.  Well in our case, we would be doing Python <-> Python calls only,
so I wonder how it would handle that.  I'll check the archives.

thanks for the response!

Preston Landers



Tue, 07 Jun 2005 03:17:25 GMT  
 Python + IIS/ASP questions (modules, namespaces, etc)

Quote:

> Sent: Thursday, December 19, 2002 1:17 PM

> [...snip...]

> So, now I am going to look at converting our Windows database code to
> using an ADO based module.  One weird thing is that the
> RecordSet.GetRows function returns stuff in a weird (Columns, Rows)
> format, instead of the (Rows, Columns) that we need.  My first pass at
> a python function to transform that is disappointingly slow.

Use zip to reorder your row/column data, to convert it
into a list of tuples [ (row1), (row2), ... ]:

    zip(*ado.getrows()) -> list

It's fairly quick.

-gustavo



Tue, 07 Jun 2005 06:43:41 GMT  
 Python + IIS/ASP questions (modules, namespaces, etc)

Quote:

> Use zip to reorder your row/column data, to convert it
> into a list of tuples [ (row1), (row2), ... ]:

>     zip(*ado.getrows()) -> list

> It's fairly quick.

> -gustavo

Ah, beautiful.  I knew that builtin function would come in handy
someday.

I'm not sure about your syntax.  I used this:

column_major_list = ado.GetRows()
row_major_list = apply(zip, column_major_list)

And since I really want all the strings as regular strings instead of
unicode, I also did this:

import types
def ununicode(x):
    if type(x) is types.UnicodeType:
        return str(x)
    else:
        return x

def stringify(rec):
    return tuple(map(ununicode, rec))

row_major_list = map(stringify, apply(zip,ado.GetRows()))

thanks for the tip!

Preston



Wed, 08 Jun 2005 01:31:04 GMT  
 Python + IIS/ASP questions (modules, namespaces, etc)

Quote:

> Sent: Friday, December 20, 2002 11:31 AM



> > Use zip to reorder your row/column data, to convert it
> > into a list of tuples [ (row1), (row2), ... ]:

> >     zip(*ado.getrows()) -> list

> > It's fairly quick.

> > -gustavo

> Ah, beautiful.  I knew that builtin function would come in handy
> someday.

> I'm not sure about your syntax.  I used this:

> column_major_list = ado.GetRows()
> row_major_list = apply(zip, column_major_list)
> [...snip...]

It's the same thing, only for Python 2.2.

In earlier versions of python, if you needed to
specify an arbitrary amount of positional arguments,
or keyword arguments, you needed 'apply' to do the
function call:

    apply(function, (pos-args-tuple), {kw-args-dict})

But, in recent versions of python, you can ommit apply
and simply specify a tuple (or list) to use as "the rest
of the positional args", and a dictionary to use as
"these other keyword args", with this syntax:

   function(*pos_args_tuple, **kw_args_dict)

So, when I write:

   zip(*ado.getrows())

Actually, this is equivalent to:

   apply(zip, tuple(ado.getrows()), None)

HTH

-gustavo



Wed, 08 Jun 2005 02:52:25 GMT  
 Python + IIS/ASP questions (modules, namespaces, etc)

Quote:

> And since I really want all the strings as regular strings instead of
> unicode, I also did this:

> import types
> def ununicode(x):
>     if type(x) is types.UnicodeType:
>         return str(x)
>     else:
>         return x

Note that this will bite your bum as soon as you have non-ASCII data in
one of your rows.

You really are better off trying to avoid converting from Unicode to
string at all - you will probably be amazed how far this will get you.

When you *do* need to convert, you should pick a real encoding, so
non-ASCII characters are handled.  On Windows systems:

      if type(x) is types.UnicodeType:
          return x.encode("mbcs")
      else:
          return x

is generally correct.

Mark.



Wed, 08 Jun 2005 07:22:58 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. Pythonwin IIS-ASP module imports (bug)

2. Accessing ASP-IIS objects in modules

3. My modules doesn't seem to reload in IIS asp pages

4. using com object written in python from iis/asp

5. IIS ASP Python 2.2 script works first time only

6. Python, ASP/IIS, KeyboardInterrupt

7. config for Python as the IIS hosted ASP script Lang

8. ideal architecture for Python/IIS/ASP/COM?

9. connect to IIS and debug ASP with python????

10. IIS + ASP + <#@Language=Python#>== performance_hit

11. Trouble with IIS Python ASP

12. Python, ASP - Namespace (again)

 

 
Powered by phpBB® Forum Software