Author freyley
Recipients docs@python, freyley, terry.reedy
Date 2010-07-27.17:29:34
SpamBayes Score 0.00027496
Marked as misclassified No
Message-id <>
In-reply-to <>
On Thu, Jun 17, 2010 at 3:30 PM, Terry J. Reedy <> wrote:
> In order for the doc maintainers to add an entry, someone knowledgeable must write it. Your paragraph of explanation is a start, but more editing is needed.
> Looking at dir(html.parser.HTMLParser) and help(...), I see that there are several public internal methods. Some have doc strings that show up with help(), some do not. I thing all should. Some are defined on HTMLParser and some inherited from the undocumented (I believe) _markupbase.ParserBase.
> I see that there are also several (completely undocumented except fir dir()) private ('_xyz') internal methods. This implies to me that the public internal methods were made public rather than private because there might be reason to override them. If so, perhaps there should be a new subsection on public internal methods to explain what is what with them. What do you think? Document just one, some, or all?


I'm looking at the HTMLParser code, and I only see unknown_decl as a
method in there that is: a) not marked as internal or doing a lot, b)
not documented. There are a number of methods which should probably be
refactored to be _methodname rather than methodname, but that's beyond
the scope of this report.

Method called when an unrecognized SGML declaration is read by the
parser. The data parameter will be the entire contents of the
declaration inside the <!...> markup. It is sometimes useful to be be
overridden by a derived class; the base class implementation throws an

There may be other undocumented methods showing up, but if so they're
part of a parent class.


Date User Action Args
2010-07-27 17:29:36freyleysetrecipients: + freyley, terry.reedy, docs@python
2010-07-27 17:29:34freyleylinkissue3874 messages
2010-07-27 17:29:34freyleycreate