Mailman 3 August 2019 - docs

[issue15248] Better explain "TypeError: 'tuple' object is not callable"
by Serhiy Storchaka Aug. 11, 2019

Aug. 11, 2019

Serhiy Storchaka <storchaka+cpython(a)gmail.com> added the comment: This is not related to this particular warning, but to how IDLE handles SyntaxWarning. See issue34857. ---------- assignee: terry.reedy -> components: +Interpreter Core -IDLE status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue15248> _______________________________________

1 0

Documentation Bug - Telnet
by Michael Faust Aug. 11, 2019

Aug. 11, 2019

Hello, I think I found a bug in the Telnet docs: https://docs.python.org/3/library/telnetlib.html In the section https://docs.python.org/3/library/telnetlib.html#telnetlib.Telnet the "open()" link should probably point to https://docs.python.org/3/library/telnetlib.html#telnetlib.Telnet.open but instead it points to https://docs.python.org/3/library/functions.html#open Best regards, Michael

2 1

[issue23220] IDLE: Document how Shell displays user code output
by Tal Einat Aug. 11, 2019

Aug. 11, 2019

Tal Einat <taleinat(a)gmail.com> added the comment: See initial working implementation of handling \r and \b characters is the shell, PR GH-15211. ---------- nosy: +taleinat _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue23220> _______________________________________

1 0

[issue23220] IDLE: Document how Shell displays user code output
by Tal Einat Aug. 11, 2019

Aug. 11, 2019

Change by Tal Einat <taleinat(a)gmail.com>: ---------- pull_requests: +14939 pull_request: https://github.com/python/cpython/pull/15211 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue23220> _______________________________________

1 0

[issue15248] Better explain "TypeError: 'tuple' object is not callable"
by Serhiy Storchaka Aug. 11, 2019

Aug. 11, 2019

Serhiy Storchaka <storchaka+cpython(a)gmail.com> added the comment: I think it would be better to open a separate issue for IDLE. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue15248> _______________________________________

1 0

[issue15248] Better explain "TypeError: 'tuple' object is not callable"
by Raymond Hettinger Aug. 11, 2019

Aug. 11, 2019

Raymond Hettinger <raymond.hettinger(a)gmail.com> added the comment: This isn't interacting well with IDLE. ==================================================== --- Works fine at the regular interactive prompt --- $ python3.8 Python 3.8.0b3 (v3.8.0b3:4336222407, Jul 29 2019, 09:46:03) [Clang 6.0 (clang-600.0.57)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> data = [ ... (1, 2, 3) # oops, missing comma! ... (4, 5, 6) ... ] <stdin>:2: SyntaxWarning: 'tuple' object is not callable; perhaps you missed a comma? Traceback (most recent call last): File "<stdin>", line 2, in <module> ==================================================== --- Behaves differently in the IDLE Shell --- Python 3.8.0b3 (v3.8.0b3:4336222407, Jul 29 2019, 09:46:03) [Clang 6.0 (clang-600.0.57)] on darwin Type "help", "copyright", "credits" or "license()" for more information. >>> data = [ (1, 2, 3) # oops, missing comma! (4, 5, 6) ] SyntaxError: 'tuple' object is not callable; perhaps you missed a comma? ---------- assignee: docs@python -> terry.reedy components: +IDLE -Documentation nosy: +rhettinger status: closed -> open _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue15248> _______________________________________

1 0

[issue37818] Behaviors of binary bitwise operators contradicting documentation
by John Rogers Aug. 11, 2019

Aug. 11, 2019

New submission from John Rogers <luinnissar(a)yahoo.com>: In Python Language Reference (version 3.7), section 6.9 it states that the arguments of binary bitwise operators must be integers. However, the following expressions work without error: True & False False | True True ^ True Each produces a boolean result (not integer) (False, True, False, respectively). Also I find that mixing booleans and integers does work too, though this time it produces integers. One can easily test it on Python home page's console window. I also tested it on my Linux box running version 3.5.3. So it appears that it has been overlooked for quite some time! As an aside: I do assume that boolean values are *distinct* from integers. If they are not, then my apologies! ---------- assignee: docs@python components: Documentation messages: 349372 nosy: The Blue Wizard, docs@python priority: normal severity: normal status: open title: Behaviors of binary bitwise operators contradicting documentation type: behavior versions: Python 3.5, Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue37818> _______________________________________

2 1

[issue37816] f-string documentation not fully accurate
by Glenn Linderman Aug. 11, 2019

Aug. 11, 2019

New submission from Glenn Linderman <v+python(a)g.nevcal.com>: I noticed the following description for f-strings: > Escape sequences are decoded like in ordinary string literals (except when a literal is also marked as a raw string). After decoding, the grammar for the contents of the string is: followed by lots of stuff, followed by > Backslashes are not allowed in format expressions and will raise an error: > f"newline: {ord('\n')}" # raises SyntaxError If f-strings are processed AS DESCRIBED, the \n would never seen by the format expression... but in fact, it does produce an error. PEP 498 has a more accurate description, that the {} parsing actually happens before the escape processing. The string or raw-string escape processing is done only to the literal string pieces. So the string content is first parsed for format expressions enclosed in {}, on the way, converting {{ and }} to { and } in the literal parts of the string, and then the literal parts are treated exactly like independent string literals (with regular or raw-string escaping performed), to be concatenated with the evaluation of the format expressions, and subsequent literal parts. The evaluation of the format expressions presently precludes the use of # and \ for comments and escapes, but otherwise tries to sort of by the same as a python expression possibly followed by a format mini-language part. I am not the expert here, just the messenger. ---------- assignee: docs@python components: Documentation messages: 349370 nosy: docs@python, v+python priority: normal severity: normal status: open title: f-string documentation not fully accurate versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue37816> _______________________________________

2 1

[issue37809] Alias typing.NamedTuple to collections
by Raymond Hettinger Aug. 10, 2019

Aug. 10, 2019

Raymond Hettinger <raymond.hettinger(a)gmail.com> added the comment: Further notes for posterity: * Anything written using collections.NamedTuple would instantly lose its backwards compatibility. * The casing of NamedTuple is more in line with the typing module: List, Deque, NamedTuple and doesn't fit well with the deque, namedtuple, and ChainMap in the collections module. * Nothing in the collections module currently requires typing, but NamedTuple can only be used with typing. * We really don't want to increase import times for collections. This proposal would defeat the entire purpose of having moved _collections_abc to a separate module outside of the collections package. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue37809> _______________________________________

1 0

[issue37809] Alias typing.NamedTuple to collections
by Ivan Levkivskyi Aug. 10, 2019

Aug. 10, 2019

Ivan Levkivskyi <levkivskyi(a)gmail.com> added the comment: > FWIW, I had updated the docs for namedtuple() to link to typing.NamedTuple. I think that should suffice. Thank you! I looked at the docs everything looks good. I think this can be closed now. ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue37809> _______________________________________

1 0