[Web-SIG] PEP 333 (19-Sep-04) Feedback

[Mark Nottingham]

Thanks for the quick response. Answers inline below.

On Sep 28, 2004, at 9:57 PM, Phillip J. Eby wrote:
>> * The same section later states "The application object must return 
>> an iterable yielding strings." Return when?
>
> When it's called, of course.  I'll change that to, "When called, the 
> application object must..."
>
>
>>  We're cautioned that the write() callable should not be used; how is 
>> the iterable returned, then?
>
> Huh?

I found the flow of calls confusing in this section; I'll think on how 
to improve it and make a concrete suggestion if I come up with 
something.


>> * In "environ Variables," it is specified that "In general, a server 
>> or gateway should attempt to provide as many other CGI variables as 
>> are applicable, including e.g. the nonstandard SSL variables such as 
>> HTTPS=on , if an SSL connection is in effect." This sentence hedges 
>> in four different ways; "In general," "should," "attempt," "as 
>> many... as are applicable." Besides the redundancy, I'm concerned 
>> about the inclusion of nonstandard variables; how will people know 
>> which ones to include? I'd suggest listing those that aren't in the 
>> CGI standard, so there's an even playing field.
>
> Is there a standard for SSL extensions to CGI?  These are really the 
> only "non-standard" variables I actually care about.  I'll tweak the 
> rest of this more or less as you suggest.

Not to my knowledge; maybe just document that one and don't mention 
others.


>> * The same section defines a number of environment variables with 
>> Boolean values (e.g., wsgi.multithread). When these definitions say 
>> "This value should be true if..." does it mean that they should be a 
>> Python types.BooleanType, or that it should evaluate to true (e.g., 
>> if wgsi.multithread: ...)?
>
> The latter; I thought this was obvious by virtue of the fact that it 
> doesn't say ``True`` in typewriter font.  Good Python style (and 
> performance) demands that one never perform truth tests by comparing 
> directly to ``True`` or ``False``, so in theory it shouldn't matter 
> unless you want to be tricky and use the value as an index.
>
> Were you actually confused by this bit, or are you just looking for 
> ambiguities?  I'd like to avoid cluttering these definitions further, 
> if possible.

Looking for ambiguities. Couldn't you fix this by saying "The value 
should evaluate to true if..."?


Cheers,

--
Mark Nottingham     http://www.mnot.net/