When the HTMLParser encounters a start tag element that includes:
  1. an unquoted attribute as the final attribute 
  2. an optional '/' character marking the start tag as self-closing
  3. no space between the final attribute and the '/' character

the '/' character gets attached to the attribute value and the element is interpreted as not self-closing.  This can be illustrated with the following:

===============================================================================

import HTMLParser

# Begin Monkeypatch
#import re
#HTMLParser.attrfind = re.compile(
#    r'((?<=[\'"\s/])[^\s/>][^\s/=>]*)(\s*=+\s*'
#    r'(\'[^\']*\'|"[^"]*"|(?![\'"])[^/>\s]*))?(?:\s|/(?!>))*')
# End Monkeypatch

class MyHTMLParser(HTMLParser.HTMLParser):
    def handle_starttag(self, tag, attrs):
        print('got starttag: {0} with attributes {1}'.format(tag, attrs))

    def handle_endtag(self, tag):
        print('got endtag: {0}'.format(tag))

MyHTMLParser().feed('<img height=1.0 width=2.0/>')

==============================================================================

Running the above code yields the output:

    got starttag: img with attributes [('height', '1.0'), ('width', '2.0/')]

Note the trailing '/' on the 'width' attribute.  If I uncomment the monkey patch, the script then yields:

    got starttag: img with attributes [('height', '1.0'), ('width', '2.0')]
    got endtag: img

Note that the trailing '/' is gone, and an endtag event was generated.

I don't think this is a bug. The HTML5 syntax spec tells:

    If an attribute using the unquoted attribute syntax is to be followed by another attribute or by the optional "/" (U+002F) character allowed in step 6 of the start tag syntax above, then there must be a space character separating the two.

So I think HTMLParser's behaviour is right.

The link is https://www.w3.org/TR/html5/syntax.html#attributes-0.

Hmm, can not say the behaviour is right. But since the HTML doesn't follows the official rule, HTMLParser's behaviour is understandable and can not be identified as incorrect.

This is not a bug, as described in the HTML5 standard[0], if an unquoted attribute value is followed by a /, the / is included (the "anything else" branch of that list).
This is also what browsers do: try to create an HTML document that includes <img title=test/> and open it in a browser, then use the inspector to examine the result -- you will see <img title="test/"></img> (at least on firefox).
HTMLParser follows the HTML5 standard, so I'm closing this as "not a bug".
Thanks anyway for the report and to Xiang for pointing out that it's not a bug.

[0]: https://www.w3.org/TR/html5/syntax.html#attribute-value-%28unquoted%29-state