[issue3874] documentation bug: HTMLParser needs to document unknown_decl
Terry J. Reedy <tjreedy@udel.edu> added the comment: I understand that getting no response to a submission is not pleasant. I do not like it either. That is partly why I have started reviewing old issues. In the past couple of weeks, I have gotten old two orphaned patches applied by updating the headers, reading the patch, and adding a first-response approval message that got the attention of someone with code-commit privileges. I hope you agree that late is better than never. I just discovered the nosy-count box on the search page. 351 open issues with a nosy count of 1 (which means no response unless someone responded and then removed themself) is too many. We need more issue reviewers. As to your message: this is *our* tracker, not my tracker. My participation is as much voluntary as yours. I hope you do not really give up on improving Python and its documentation. I did not expect that you *should* have known submission details. That is why I tried to inform you. In particular, when an issue is marked as 'documentation', it is automatically assigned to 'docs@python', a pseudo-user standing in for people who handle doc revisions. Now they will see this issue, whereas they would not have before. Please excuse me for not remembering the title as I responded to the message. It is best if message text stands alone. Again, I hope you would agree that an somewhat ignorant response may be better than none. 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? ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue3874> _______________________________________
jeff <freyley@gmail.com> added the comment: On Thu, Jun 17, 2010 at 3:30 PM, Terry J. Reedy <report@bugs.python.org> 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?
Terry, 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. HTMLParser.unknown_decl(data)ΒΆ 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 HTMLParseError. There may be other undocumented methods showing up, but if so they're part of a parent class. Thanks, Jeff ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue3874> _______________________________________
participants (2)
-
jeff -
Terry J. Reedy