[Web-SIG] WSGI tests

[Phillip J. Eby]

At 12:23 PM 9/29/04 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>Actually, it just occurred to me that there *is* a legitimate test you 
>>can do for SCRIPT_NAME and PATH_INFO: at least *one* of them must be 
>>present and non-blank, because if you're at the site root, SCRIPT_NAME is 
>>empty and PATH_INFO has to be '/'.  (Or the other way around, the CGI 
>>spec isn't clear on this, but Apache CGI puts the '/' in PATH_INFO.)
>
>OK... I guess the root of a domain is an odd case, because I can't imagine 
>what the difference between SCRIPT_NAME="/", PATH_INFO="" or 
>SCRIPT_NAME="", PATH_INFO="/" would mean.
>
>On further thought, I think it doesn't make sense for SCRIPT_NAME to be 
>"/".  Because PATH_INFO must always start with a "/", SCRIPT_NAME must be 
>"" if there's any path (unless we get double /'s when reconstructing the 
>URL, which wouldn't be good).  So I think I'm going to make the test 
>include SCRIPT_NAME != "/".  The general case would say that SCRIPT_NAME 
>should not end with a /, but I don't feel 100% confident that that's correct.

Actually, you're right: SCRIPT_NAME should not end with a '/', because it 
would have to be part of PATH_INFO in that case.


>>>>By the way, I found another issue with lint: IteratorWrapper doesn't 
>>>>close the original iterable if it had a close() method.
>>>
>>>
>>>Fixed as well.
>>
>>Actually, no.  Lint's iterator close() is still broken.  You have to use 
>>close() on the *iterable*, not on iter(iterable).  The two may be 
>>different objects, since an iterable may return a separate iterator object.
>
>This was something I felt a little ambiguous about.  I assume the server 
>always must iterate over iter(app_iter), it can't iterate over app_iter 
>directly.

Not precisely true; see below.


>   When using a "for" loop there's not much distinction, but if you access 
> the .next() methods directly there would be.  Anyway, I'm a little fuzzy 
> when __iter__ gets called implicitly.  I was suprised that it seemed to 
> get called twice when iterating with a simple for look, and I had to add 
> IteratorWrapper.__iter__.

PEP 234 describes the iterator protocol, but here's a short summary:

* An "iterable" has an __iter__ method (tp_iter slot at the C level)

* An "iterator" has an __iter__ method *and* a next method (tp_iter_next slot)

'for' loops work on "iterables", so they call __iter__.  Typically, an 
iterator's __iter__ returns self, so this is idempotent if you're iterating 
over an iterator.

WSGI apps must return an *iterable*.  An iterator is of course also an 
iterable.



>>I'm pretty much coming to the conclusion that WSGI is no longer "simple", 
>>alas.  For it to actually be usable, there's going to have to be a 
>>reference library, as well as tests.  I'm going to keep pecking away at 
>>your lint program, and eventually your other test facilities as well, so 
>>that I'll have something to test the reference library with.  :)
>
>The basic mechanics are still reasonably simple, but there's a lot of 
>smaller things to consider.  So I don't think WSGI has become that much 
>more complicated, we've just come to appreciate complexities that were 
>there all along.
>
>Also, should we be putting all of this code in a single repository?

Eventually, we should probably use the Python CVS sandbox.  For now, we 
don't really have any duplication taking place AFAICT.  Once I have 
something resembling a coherent reference library, I'll put it there, anyway.