A critique of cgi.escape

[Brian Quinlan]

Jon Ribbens wrote:
> I guess, if you mean the part of the thread which went "it'll break
> existing code", "what existing code"? "existing code" "but what
> existing code?" "i dunno, just, er, code" "ok *how* will it break it?"
> "i dunno, it just will"?

See below for a possible example.

>> BTW, I am curious about how you do unit testing. The example that I used 
>> in my summary is a very common pattern but would break in cgi.escape 
>> changed it's semantics. What do you do instead?
> 
> To be honest I'm not sure what *sort* of code people test this way. It
> just doesn't seem appropriate at all for web page generating code.

Well, there are dozens (hundreds?) of templating systems for Python. 
Here is a (simplified/modified) unit test for my company's system (yeah, 
we lifted some ideas from Django):

test.html
---------
<p>{foo | escape}</p>

test.py
-------
t = Template("test.html")
t['foo'] = 'Brian -> "Hi!"'
assert str(t) == '<p>Brian -> "Hi"</p>'

So how would you test our template system?

> Web
> pages need to be manually viewed in web browsers, and validated, and
> checked for accessibility. 

True.

> Checking they're equal to a particular
> string just seems bizarre (and where does that string come from
> anyway?)

Maybe, which is why I'm asking you how you do it. Some of our web 
applications contain 100s of script generated pages. Testing each one by 
hand after making a change would be completely impossible. So we use 
HTTP scripting for testing purposes i.e. send this request, grab the 
results, verify that the test in the element with id="username" equals 
"Brian Quinlan", etc. The test also validates that each page is well 
formed. We also view each page at some point but not every time a 
developer makes a change that might (i.e. everything) affect the entire 
system.

Cheers,
Brian