homepage

Python 2.7 HTMLParse.py lines 185-199 (similar lines still exist in Python 3.4)
 match = charref.match(rawdata, i)
 if match:
 ...
 else:
 if ";" in rawdata[i:]: #bail by consuming &#
 self.handle_data(rawdata[0:2])
 i = self.updatepos(i, 2)
 break
if you feed a broken charref, that is non-numeric, it will pass whatever random string that happened to be at the start of rawdata to handle_data(). Eg:
p = HTMLParser()
p.handle_data = lambda x: sys.stdout.write(x)
p.feed('<p>&#foo;</p>')
will print '<p' which is clearly wrong. I think the intention of the code is to pass '&#', which seems saner.

Thanks for the report, this is indeed a bug.
This behavior was covered by a test (see Lib/test/test_htmlparser.py:164), but _run_check feeds the chars one by one to the parser, and in that case it works correctly. While feeding the parser a whole chunk I was able to reproduce the bug. This should be fixed, and the behavior of _run_check should probably be changed too -- maybe it could test both the char-by-char and the regular feeding.

Here's a patch against 2.7.

New changeset 0d50b5851f38 by Ezio Melotti in branch '2.7':
#20288: fix handling of invalid numeric charrefs in HTMLParser.
http://hg.python.org/cpython/rev/0d50b5851f38
New changeset 32097f193892 by Ezio Melotti in branch '3.3':
#20288: fix handling of invalid numeric charrefs in HTMLParser.
http://hg.python.org/cpython/rev/32097f193892
New changeset 92b3928bfde1 by Ezio Melotti in branch 'default':
#20288: merge with 3.3.
http://hg.python.org/cpython/rev/92b3928bfde1 

This is now fixed, thanks for the report!
> This should be fixed, and the behavior of _run_check should probably be
> changed too -- maybe it could test both the char-by-char and the
> regular feeding.
I created #20623 to track this.