Mailman 3 August 2013 - docs

[issue13918] locale.atof documentation is missing func argument
by Cédric Krier 23 Oct '14

23 Oct '14

New submission from Cédric Krier <cedric.krier(a)b2ck.com>: atof has a func argument used to instantiate the result but it is missing in the documentation. ---------- assignee: docs@python components: Documentation messages: 152430 nosy: ced, docs@python priority: normal severity: normal status: open title: locale.atof documentation is missing func argument type: enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13918> _______________________________________

8 26

[issue13769] json.dump(ensure_ascii=False) return str instead of unicode
by Марк Коренберг 23 Oct '14

23 Oct '14

New submission from Марк Коренберг <socketpair(a)gmail.com>: $ ipython In [1]: type(json.dumps({'a':'b'}, ensure_ascii=False)) Out[1]: <type 'str'> In [2]: type(json.dumps({'a':u'b'}, ensure_ascii=False)) Out[2]: <type 'unicode'> ----------------------- Documentation: If ensure_ascii is False, then the return value will be a unicode instance. -------------------------------- Not applicable to python3 ---------- assignee: docs@python components: Documentation, Library (Lib) messages: 151066 nosy: docs@python, mmarkk priority: normal severity: normal status: open title: json.dump(ensure_ascii=False) return str instead of unicode type: behavior versions: Python 2.6, Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13769> _______________________________________

7 13

[issue16863] Argparse tutorial outdated
by Charlie Dimino 22 Oct '14

22 Oct '14

New submission from Charlie Dimino: http://docs.python.org/2/howto/argparse.html Error message in the first example is outdated, may indicate further out of date information on page. Example: The tutorial says: prog.py: error: the following arguments are required: echo When the actual error received is: prog.py: error: too few arguments ---------- assignee: docs@python components: Documentation messages: 179041 nosy: Charlie.Dimino, docs@python priority: normal severity: normal status: open title: Argparse tutorial outdated versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16863> _______________________________________

8 13

[issue15204] Deprecate the 'U' open mode
by Serhiy Storchaka 19 Oct '14

19 Oct '14

New submission from Serhiy Storchaka <storchaka(a)gmail.com>: Since Python 2.3 many open functions supports "Universal line mode" (PEP 278). Since 3.0 (and 2.6) PEP 3116 suggests better alternative -- io.TextWrapper. Now support for the 'U' mode in the different open functions is heterogeneous. Some functions simply ignore the 'U' mode (but accept it), others perceive it as a synonym for text-mode, others just pass it on lower lever, other attempt to implement it, but the implementation is obtained imperfect and contradictory (as in ZipExtFile). The documentation for built-in open does not advise the use of the 'U' mode. The 'U' mode support cumbersome. I propose to deprecate the 'U' mode. If someone wanted to work with the universal line support, he'll surely need to work with encodings too, and io.TextWrapper provides is better choise. The deprecation plan for the 'U' mode of open functions might be as follow: 3.3. Deprecating the 'U' mode in docs for all opens (building open, io.open, codecs.open, gzip.open, ZipFile.open, etc). Add suggestion about io.TextWrapper. 3.4. Raise a warning on use of the 'U' mode. 3.5. Raise an exception on use of the 'U' mode. 3.6 (or 4.0?). Remove the 'U' mode processing code. As the first stage involves only the changes to the documentation, I hope deprecation can starts in 3.3. ---------- assignee: docs@python components: Documentation, IO, Library (Lib) messages: 164142 nosy: docs@python, storchaka priority: normal severity: normal status: open title: Deprecate the 'U' open mode type: behavior versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15204> _______________________________________

14 34

[issue12965] longobject: documentation improvements
by Stefan Krah 14 Oct '14

14 Oct '14

New submission from Stefan Krah <stefan-usenet(a)bytereef.org>: I think the integer objects documentation could be clearer on a couple of points: - Despite being listed under "Concrete Objects Layer", some functions implicitly accept anything with an __int__() method. Currently only the PyLong_AsLong() documentation states this explicitly. The patch clearly distinguishes between functions that duck type and functions that don't. - The patch replaces "is greater than *_MAX" instances with "out of bounds" to include the other error condition "is less than *_MIN". Additionally, the patch fixes comments in longobject.c that don't state the duck typing behavior. ---------- assignee: docs@python components: Documentation files: longobject-doc.diff keywords: patch messages: 143922 nosy: docs@python, mark.dickinson, skrah priority: normal severity: normal stage: patch review status: open title: longobject: documentation improvements type: feature request versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file23133/longobject-doc.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12965> _______________________________________

3 11

[issue15414] os.path.join behavior on Windows (ntpath.join) is unexpected and not well documented
by R. David Murray 10 Oct '14

10 Oct '14

New submission from R. David Murray <rdmurray(a)bitdance.com>: In looking at another os.path.join documentation issue I tried the Windows join to see if it matched the docs, and found that it was very unclear. I searched the tracker and found Issue 1669539, which contains much relevant discussion but also much discussion of possible enhancements. So I'm opening a new issue *just* about what I see as the current bugs in the os.path.join docs and ntpath.join implementation. I'm not qualified to fix this, not being a Windows user, but it is clear to me that the documentation of os.path.join for Windows is unclear (it does not indicate what is considered an absolute path on Windows) and wrong (\foo will *not* restart the path if it is the second element and follows a drive specification, but it does any other time), and that the current behavior may have a bug if, as seems to be implied by the issue 1669539 discussion, something that looks like a drive specification in the middle of a path is invalid on Windows. If this last is not a bug, it should be mentioned in the documentation, since the actual behavior is counter-intuitive. ---------- assignee: docs@python components: Documentation, Windows keywords: easy messages: 166065 nosy: brian.curtin, christian.heimes, docs@python, eckhardt, ezio.melotti, jorend, mhammond, r.david.murray, terry.reedy, tim.golden priority: normal severity: normal status: open title: os.path.join behavior on Windows (ntpath.join) is unexpected and not well documented type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15414> _______________________________________

8 12

[issue10583] Encoding issue with chm help in 2.7.1
by flashk 06 Oct '14

06 Oct '14

New submission from flashk <flashk(a)gmail.com>: I just updated to Python 2.7.1 and noticed a small issue with the chm help file. The search results tab displays incorrect characters for various topic titles. It seems to be an encoding issue. For example, searching for 'json' yields the following results: - 18.2 json â€” JSON encoder and decoder - Whatâ€™s New in Python 2.6 I noticed this issue on Windows XP 32-bit and Windows 7 64-bit. This issue does not exist with the 2.7 chm file. ---------- assignee: docs@python components: Documentation, Windows messages: 122857 nosy: docs@python, flashk priority: normal severity: normal status: open title: Encoding issue with chm help in 2.7.1 type: behavior versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10583> _______________________________________

7 11

[issue16155] Some minor doc fixes in Doc/faq
by Ravi Sinha 06 Oct '14

06 Oct '14

New submission from Ravi Sinha: - help(fn) which in the REPL leads to a new pager/ display - seems to be difficult to test with doctest - it does not seem to pick the whitespace in the docs and does not match - Doc/faq/general.rst - os.path.isdir returns True or False, not 0 or 1 as in the docs, but I didn't know if I should change that - Doc/faq/windows.rst ---------- assignee: docs@python components: Documentation files: doc_faq.patch keywords: patch messages: 172254 nosy: Ravi.Sinha, chris.jerdonek, docs@python, r.david.murray, terry.reedy priority: normal severity: normal status: open title: Some minor doc fixes in Doc/faq type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file27463/doc_faq.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16155> _______________________________________

8 12

[issue17057] Data model documentation grammar
by Hobs 06 Oct '14

06 Oct '14

New submission from Hobs: New-style and old-style class expalanation in the datamodel section has minor grammatical errors and one minor ambiguity that could be improved. http://docs.python.org/2/reference/datamodel.html#new-style-and-classic-cla… * "independently of" should always be "indepenent of" * single hyphens (-) should be double-hyphens (--) for an m-dash * "flavour" should be "flavor" (used 100x more often in docs.python) * "only the symantics of..." is ambiguous. can't tell if 'only' modifies 'symantics' or 'new-style classes'? ---------- assignee: docs@python components: Documentation files: datamodel-reference-docs.patch keywords: patch messages: 180812 nosy: Hobson.Lane, docs@python priority: normal severity: normal status: open title: Data model documentation grammar type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file28876/datamodel-reference-docs.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17057> _______________________________________

3 2

[issue12148] Clarify "or-ing together" doctest option flags
by ekorn 06 Oct '14

06 Oct '14

New submission from ekorn <jonovik(a)gmail.com>: Combining multiple option flags to doctest.testmod(optionflags=...) requires the bitwise or operator |, not plain "or". I therefore suggest rewording "or-ing together individual option flags." to "or-ing together individual option flags, using the 'bitwise or' operator |.", perhaps with a link to http://docs.python.org/reference/expressions.html#binary-bitwise-operations. Example: """ Doctest option flags must be or-ed together with '|', not 'or'. >>> print "A B C" A B... """ import doctest print "Combining option flags using bitwise '|'..." doctest.testmod(optionflags=doctest.NORMALIZE_WHITESPACE | doctest.ELLIPSIS) print "Combining option flags using logical 'or'..." doctest.testmod(optionflags=doctest.NORMALIZE_WHITESPACE or doctest.ELLIPSIS) ---------- assignee: docs@python components: Documentation messages: 136509 nosy: docs@python, ekorn priority: normal severity: normal status: open title: Clarify "or-ing together" doctest option flags versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12148> _______________________________________

6 8