Mailman 3 November 2010 - docs

[issue10351] Add autocompletion for keys in dictionaries
by Valery Khamenya Nov. 18, 2010

Nov. 18, 2010

Valery Khamenya <khamenya(a)gmail.com> added the comment: Guys, do you expect anythig else from me in respect to this issue? Let me know it before my non-stopable garbage collector wipes all the details from my brain away :) ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10351> _______________________________________

1 0

[issue10446] pydoc3 links to 2.x library reference
by Alexander Belopolsky Nov. 17, 2010

Nov. 17, 2010

Changes by Alexander Belopolsky <belopolsky(a)users.sourceforge.net>: ---------- Removed message: http://bugs.python.org/msg121440 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10446> _______________________________________

1 0

[issue10446] pydoc3 links to 2.x library reference
by Alexander Belopolsky Nov. 17, 2010

Nov. 17, 2010

Alexander Belopolsky <belopolsky(a)users.sourceforge.net> added the comment: On Wed, Nov 17, 2010 at 11:21 PM, Ron Adam <report(a)bugs.python.org> wrote: .. > I noticed in your patch, the disclaimer only prints when pydoc can find a doc location (docloc is not None). This is not a disclaimer, but an explanation of the relationship between pydoc pages and the reference manual. > So it may not get displayed at all depending on how python is installed. docloc should not be None for standard library modules. This is a separate issue. > I also think having it on every page may be a bit overly cautious. (IMHO) In text viewer you only see one page at a time. In HTML you may put it on the index or start page. > I'm also not sure it is correct to have that when viewing third party modules as the doc location > in those cases will be broken anyway. > docloc is None for 3rd party modules (pydocs checks for site-packages component in path). The logic is not very robust, but that is a separate issue. > The obvious places to put it are: > * top of the pydoc html module index. (first page displayed) That's fine. > * in the welcome message for interactive help() > * help(help) > * help(pydoc) > No, these places are almost never seen. Also, one should not think of this as a disclaimer, but as an explanation of why she is shown a link to a reference page when full documentation is already displayed. > It can still be defined in one location and then use "+ pydoc_disclaimer" in the desired locations. Sure. Just don't call it "disclaimer". Maybe Doc.REFTEXT constant next to Doc.PYTHONDOCS? ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10446> _______________________________________

1 0

[issue10446] pydoc3 links to 2.x library reference
by Ron Adam Nov. 17, 2010

Nov. 17, 2010

Ron Adam <ron_adam(a)users.sourceforge.net> added the comment: I noticed in your patch, the disclaimer only prints when pydoc can find a doc location (docloc is not None). So it may not get displayed at all depending on how python is installed. I also think having it on every page may be a bit overly cautious. (IMHO) I'm also not sure it is correct to have that when viewing third party modules as the doc location in those cases will be broken anyway. The obvious places to put it are: * top of the pydoc html module index. (first page displayed) * in the welcome message for interactive help() * help(help) * help(pydoc) It can still be defined in one location and then use "+ pydoc_disclaimer" in the desired locations. ---------- nosy: +ron_adam _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10446> _______________________________________

2 1

[issue10446] pydoc3 links to 2.x library reference
by Éric Araujo Nov. 17, 2010

Nov. 17, 2010

Éric Araujo <merwok(a)netwok.org> added the comment: > The point of this bug report was that 3.x pydoc was sending users to > 2.7, which is clearly unacceptable. Agreed. My reply about x.y vs. x.y+1 was a reaction to your patch, not a misunderstanding of the point of this bug. > As long as documentation bug fixes are backported to maintenance > branches, I don't see an advantage in consulting 3.2 when developing for 3.1. I prefer version-specific docs too, but the thread on python-dev seemed to show I was not in the majority. > Now, I keep this issue open to decide if we should backport this to > 2.7 where this is not a bug (yet), but will be when default docs > switch to 3.x. What do you think? +1 for backporting. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10446> _______________________________________

1 0

[issue10446] pydoc3 links to 2.x library reference
by Éric Araujo Nov. 17, 2010

Nov. 17, 2010

Éric Araujo <merwok(a)netwok.org> added the comment: >> 1) I assume you have checked that this code does not produce two newlines (one in the string, >> one from the print function or write method): > Yes, it should be clear from the output that I presented above. Okay, I had missed that. > I think TextDoc.indent() takes care of the trailing '\n'. What is take care? Removing it? > That won't work for maintenance branches. (I am not even sure docs are > built for maintenance branches.) 3.1 and 2.7 docs are rebuilt. > I am not so sure about micro-version There is only one version* directive which uses a micro number. It’s a bit unfortunate. > If there was say latest/X.Y, I would use that. Wait - > there is: docs.python.org/X.Y. Would you prefer that? My point was that people used 2.7 docs even when developing for 2.6. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10446> _______________________________________

2 1

unicodedata documentation refers to the wrong version of unicode
by Alexander Belopolsky Nov. 17, 2010

Nov. 17, 2010

""" This module provides access to the Unicode Character Database which defines character properties for all Unicode characters. The data in this database is based on the UnicodeData.txt file version 5.2.0 which is publicly available from ftp://ftp.unicode.org/. """ http://docs.python.org/library/unicodedata.html >>> import unicodedata >>> unicodedata.unidata_version '6.0.0' I suggest that the text be re-worded to avoid direct version reference and refer to unidata_version instead. Same problem in unicodedata docstring.

1 1

[issue10446] pydoc3 links to 2.x library reference
by Alexander Belopolsky Nov. 17, 2010

Nov. 17, 2010

Alexander Belopolsky <belopolsky(a)users.sourceforge.net> added the comment: Reopening to consider changing just the link (not other changes) in 2.7. At some point http://docs.python.org/library will point to 3.x and we get a bug in 2.7. ---------- status: closed -> open versions: +Python 2.7 -Python 3.1, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10446> _______________________________________

1 0

[issue10446] pydoc3 links to 2.x library reference
by Alexander Belopolsky Nov. 17, 2010

Nov. 17, 2010

Changes by Alexander Belopolsky <belopolsky(a)users.sourceforge.net>: ---------- Removed message: http://bugs.python.org/msg121412 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10446> _______________________________________

1 0

[issue10446] pydoc3 links to 2.x library reference
by Alexander Belopolsky Nov. 17, 2010

Nov. 17, 2010

Changes by Alexander Belopolsky <belopolsky(a)users.sourceforge.net>: ---------- Removed message: http://bugs.python.org/msg121414 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10446> _______________________________________

1 0