A critique of cgi.escape

[Paul Boddie]

Simon Brunning wrote:
> On 26 Sep 2006 15:53:46 GMT, Jon Ribbens <jon+usenet at unequivocal.co.uk> wrote:
> > 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. Web
> > pages need to be manually viewed in web browsers, and validated, and
> > checked for accessibility. Checking they're equal to a particular
> > string just seems bizarre (and where does that string come from
> > anyway?)
>
> The kind of acceptance testing that you are talking about is very
> important, but you can't automate "Does it look OK in a browser?".
> Unit tests suitable for automation don't have anything to work with
> *but* the generated HTML.

I can understand the disbelief that a straight string comparison
involving HTML might be a robust enough test for the output of a Web
application, given that potentially many equivalent representations of
some piece of text may exist, and especially given the typical
unpredictability of many XML-based solutions with respect to things
like whitespace, encodings, entity usage, and the like. On the other
hand, the initial complaint in this thread, whilst reasonable in the
context of some ideal function for "quoting stuff in HTML pages", is
somewhat inappropriate in the context of modifying an existing, mature
function which is now in ubiquitous usage. In order to minimise the
unpredictability of solutions, we should avoid making fundamental
changes especially at the lower levels of such solutions.

I can't remember whether I have any code using cgi.escape, although
since I usually use XML APIs rather than writing HTML manually, I
suspect that I haven't. Nevertheless, the breakage potentially caused
by even one call site involving a modified variant of cgi.escape would
be enough for most people to consider reimplementing the semantics of
the existing function, thus undermining the inclusion of such a
function in the standard library in the first place.

Paul