Terry J. Reedy <tjre...@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 'd...@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 <rep...@bugs.python.org>
<http://bugs.python.org/issue3874>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
