homepage

cgi.escape() really belong in the new 'html' package.

I'm guessing that this has simply slipped under the radar.

Yep since it is not a critical change. If someone came up with a patch to move the code and docs over, make cgi.escape use the moved code, and add a PendingDeprecationWarning then it would get done.

In light of #9061, it should also start quoting single quotes when the arg is true.
Since this function is called a LOT, it might also make sense to trivially implement it in C.
If there are no objections, I can do that for 3.2.

I'm attaching a patch against py3k trunk that moves the function to the html module and fixes the documentation as Brett asked for. It also changes all the occurrences of cgi.escape I found for html.escape .

Looks good already. Two points:
* if we do the move, we should finally make sure all problematic characters are escaped. For now, I think the single quote is the most important one in attribute mode.
* the new docs for cgi.escape() are missing a newline between signature and body.

Thanks Georg for the review, I'm attaching a new patch with those problems fixed.
The new patch escapes ' when the quote parameter is true, and / always.

The actual implementation seems to be missing in the new patch; also the docs are not updated.
Is it necessary to escape the slash?

Sorry about that, I have no idea how I managed to generate that diff.
I'm attaching the correct patch.
About the slash, there's a link in #9061 that recommends to escape the slash too because it's used to close tags in HTML. Is there any chance that escaping it could cause problems?

The link says "forward slash is included as it helps end an HTML entity", which I don’t understand.

Encoding the forward slash should not cause problems, but the quote
 "forward slash is included as it helps end an HTML entity"
is confused; there's no need or additional value in escaping the forward slash.

I'm attaching a new patch without escaping the slash.

The docs are still not updated for the quote.
I wonder if we shouldn't make the second argument True by default, while we're at it (or ignore it altogether and always escape everything) -- it would make the escape() much safer to use.
Also quoting "'" already introduces incompatibility if someone compares the result literally, so I would not worry about additional incompatibilities so much.

I'm attaching a new patch with the documentation updated.
I agree with Georg that it'd be better to escape everything by default. Are there any good reasons not to?

Refined and applied the patch in r85531. Thanks all!