Mailman 3 August 2013 - docs

[issue18669] curses.chgat() moves cursor, documentation says it shouldn't
by productivememberofsociety666 04 Nov '17

04 Nov '17

New submission from productivememberofsociety666: According to docs.python.org/2/library/curses.html#chgat (or any other version), curses.chgat() is not supposed to move the cursor at all. This is true if you don't give it x,y coordinates, but if you do, the cursor does in fact move to those coordinates, since it then uses C curses's mvchgat() internally and doesn't correct the position afterwards. See included file for demonstration: Expected output is: one two Actual output is: two Fix the documentation or fix the code :-) ---------- assignee: docs@python components: Documentation, Extension Modules files: chgat-bug.py messages: 194552 nosy: docs@python, productivememberofsociety666 priority: normal severity: normal status: open title: curses.chgat() moves cursor, documentation says it shouldn't type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file31175/chgat-bug.py _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18669> _______________________________________

6 10

[issue17418] Documentation Bug
by Gurmeet Singh 28 Oct '17

28 Oct '17

New submission from Gurmeet Singh: Incompletely explained documentation at 2 places: 1. http://docs.python.org/3/library/functions.html#open The buffering argument is not correctly explained when setting to a positive argument in binary mode. 2. http://docs.python.org/3/library/os.html#os.open It is not very clear where to find descriptions of the arguments of this function. Where to find the required information and where to find C run-time documentation could be explained in following preferably: (Python/C API Reference Manual) http://docs.python.org/3/c-api/index.html and / or (The Python Standard Library) http://docs.python.org/3/library and / or (Python Runtime Services) http://docs.python.org/3/library/python.html A hyperlink may be added if so felt. ---------- assignee: docs@python components: Documentation messages: 184166 nosy: docs@python, gsingh priority: normal severity: normal status: open title: Documentation Bug versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17418> _______________________________________

4 6

[issue15472] Itertools doc summary table misdocuments some arguments
by Éric Araujo 16 Sep '17

16 Sep '17

New submission from Éric Araujo <merwok(a)netwok.org>: In the tables near the top of http://docs.python.org/library/itertools , some functions like cycle have an example that uses “seq”, which is interpreted as “sequence” but the functions do work with any iterable. ---------- assignee: docs@python components: Documentation messages: 166594 nosy: docs@python, eric.araujo, rhettinger priority: normal severity: normal status: open title: Itertools doc summary table misdocuments some arguments versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15472> _______________________________________

4 7

[issue15427] Describe use of args parameter of argparse.ArgumentParser.parse_args
by Steven Bethard 10 Sep '17

10 Sep '17

New submission from Steven Bethard <steven.bethard(a)gmail.com>: >From http://bugs.python.org/issue14191#msg155202: ArgumentParser.parse_args(args=None, namespace=None) ... However, nowhere is the args= parameter explained. One example is given at the end of 15.4.4.6 showing the use of args= which apparently accepts a list of parameters, similar to the positional list of parameters that are used in all the other examples. It might be nice to clarify that. ---------- assignee: docs@python components: Documentation messages: 166174 nosy: bethard, docs@python priority: normal severity: normal status: open title: Describe use of args parameter of argparse.ArgumentParser.parse_args type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15427> _______________________________________

5 10

[issue16988] argparse: PARSER option for nargs not documented
by Robert Leenders 04 Sep '17

04 Sep '17

New submission from Robert Leenders: There is a value for nargs: PARSER="A..." which is not documented at http://docs.python.org/3.4/library/argparse.html#nargs. The docstring for the action class in argparse.py also does not list PARSER as a valid value for nargs. In argparse.py on line 2199-2201 it says: # Allow one argument followed by any number of options or arguments elif nargs == PARSER: nargs_pattern = '(-*A[-AO]*)' This is the only hint that I could find on what it is about. ---------- assignee: docs@python components: Documentation messages: 180155 nosy: ReDAeR, bethard, docs@python priority: normal severity: normal status: open title: argparse: PARSER option for nargs not documented type: enhancement versions: Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16988> _______________________________________

5 4

[issue12067] Doc: remove errors about mixed-type comparisons.
by Terry J. Reedy 24 Aug '17

24 Aug '17

New submission from Terry J. Reedy <tjreedy(a)udel.edu>: Current 3.2 doc, 5.9. Comparisons, has this paragraph about mixed-type comparisons. "The operators <, >, ==, >=, <=, and != compare the values of two objects. The objects need not have the same type. If both are numbers, they are converted to a common type. Otherwise, the == and != operators *always* consider objects of different types to be unequal, while the <, >, >= and <= operators raise a TypeError when comparing objects of different types that do not implement these operators for the given pair of types. You can control comparison behavior of objects of non-built-in types by defining rich comparison methods like __gt__(), described in section Basic customization." Sentence 3: "If both are numbers, they are converted to a common type." I suspect it would be more true to say 'common internal type' as I would not think it a language requirement to produce Python objects. In any case, I think it is only true for built-in number types, and I do not see that qualification anywhere previously. That aside, it does not appear to be true for Decimals and Fractions in 2.7.1. Sentence 4: first clause is only true for built-in types. That qualification is not obvious to everyone, as evidenced by a current python-list sub thread. For 2.7, which has a different continuation, I suggest adding 'built-in' before 'objects of'. For 3.2/3, I suggest deleting '*always*' and adding a comma after 'TypeError' so that the 'when' condition applies to equality comparisons also. After discussion about same-type comparisons, there is another paragraph about mixed-type comparison: "Comparison of objects of the differing types depends on whether either of the types provide explicit support for the comparison. Most numeric types can be compared with one another, but comparisons of float and Decimal are not supported to avoid the inevitable confusion arising from representation issues such as float('1.1') being inexactly represented and therefore not exactly equal to Decimal('1.1') which is. When cross-type comparison is not supported, the comparison method returns NotImplemented. This can create the illusion of non-transitivity between supported cross-type comparisons and unsupported comparisons. For example, Decimal(2) == 2 and 2 == float(2) but Decimal(2) != float(2)." I suggest deleting this entirely. The first sentence and first clause of the second repeat what was said above. The rest is obsolete as float/decimal comparisons *are* implemented in 2.7.1 and 3.2.0. ---------- assignee: docs@python components: Documentation keywords: easy messages: 135873 nosy: docs@python, rhettinger, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Doc: remove errors about mixed-type comparisons. versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12067> _______________________________________

15 71

[issue12887] Documenting all SO_* constants in socket module
by Sandro Tosi 22 Aug '17

22 Aug '17

New submission from Sandro Tosi <sandro.tosi(a)gmail.com>: spinning off msg142613 - it would be interesting to have in the socket module documentation also an explanation of all the several SO_ flags available; even a compact table could be ok; or even a link to a remote reference for them. ---------- assignee: docs@python components: Documentation messages: 143428 nosy: docs@python, eric.araujo, ezio.melotti, sandro.tosi priority: normal severity: normal stage: needs patch status: open title: Documenting all SO_* constants in socket module versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12887> _______________________________________

5 5

[issue14345] Document socket.SOL_SOCKET
by anatoly techtonik 11 Aug '17

11 Aug '17

New submission from anatoly techtonik <techtonik(a)gmail.com>: socket.get/setsockopt() docs can be improved by providing description for SOL_SOCKET constant, and link to source code for other level constants and socket level options. ---------- assignee: docs@python components: Documentation messages: 156140 nosy: docs@python, techtonik priority: normal severity: normal status: open title: Document socket.SOL_SOCKET _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14345> _______________________________________

3 3

[issue11230] "Full unicode import system" not in 3.2
by John 19 Jul '17

19 Jul '17

New submission from John <jh45dev(a)gmail.com>: A few months ago I read that in 3.2 it will be possible to import modules that are located on paths containing any unicode character. (more precisely, with chars not in the local code page) After an hour or two trying to get this to work in 3.2rc3, I went looking for clues, and found these 2 messages in which Victor Stinner says this feature is delayed until Python 3.3: http://bugs.python.org/issue3080#msg126514 http://bugs.python.org/issue10828#msg125787 Could you please make it clear in documentation and web pages, that this feature is not working yet. The Python 3.2 download page includes this: "countless fixes regarding bytes/string issues; among them full support for a bytes environment (filenames, environment variables)" and I guessed this must cover importing from any unicode path, as there was no mention that such importing had been abandoned for this version. -- jh ---------- assignee: docs@python components: Documentation messages: 128711 nosy: docs@python, jh45 priority: normal severity: normal status: open title: "Full unicode import system" not in 3.2 versions: Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11230> _______________________________________

7 11

[issue15360] Behavior of assigning to __dict__ is not documented
by Davide Rizzo 13 Jul '17

13 Jul '17

New submission from Davide Rizzo <sorcio(a)gmail.com>: The documentation (at least the obvious places, see Doc/reference/datamodel.rst) says classes and class instances have the '__dict__' attribute, but nothing is said about what happens when assigning to it (like obj.__dict__ = something). As far as I understand that's undefined behavior and other implementations may not work the same as CPython (and CPython itself behaves differently between versions). I'd submit a documentation patch if I knew how to specify this matter. Maybe just say the behavior is not defined? ---------- assignee: docs@python components: Documentation, Interpreter Core messages: 165538 nosy: davide.rizzo, docs@python priority: normal severity: normal status: open title: Behavior of assigning to __dict__ is not documented versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15360> _______________________________________

8 8