Mailman 3 March 2018 - docs

[issue30076] Opcode names BUILD_MAP_UNPACK_WITH_CALL and BUILD_TUPLE_UNPACK_WITH_CALL are too long
by Serhiy Storchaka 22 Mar '18

22 Mar '18

Change by Serhiy Storchaka <storchaka+cpython(a)gmail.com>: ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python stage: -> needs patch versions: +Python 3.6, Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue30076> _______________________________________

1 0

[issue25836] Documentation of MAKE_FUNCTION is still incorrect
by Russell Keith-Magee 22 Mar '18

22 Mar '18

New submission from Russell Keith-Magee: Refs Issue16554, Issue13026, Issue14349, and probably others. The documentation for the interpretation of the argc argument to MAKE_FUNCTION in Doc/library/dis.rst is incorrect. As of 13 August 2015, the docs say: """ Pushes a new function object on the stack. From bottom to top, the consumed stack must consist of: * ``argc & 0xFF`` default argument objects in positional order * ``(argc >> 8) & 0xFF`` pairs of name and default argument, with the name just below the object on the stack, for keyword-only parameters * ``(argc >> 16) & 0x7FFF`` parameter annotation objects * a tuple listing the parameter names for the annotations (only if there are ony annotation objects) * the code associated with the function (at TOS1) * the :term:`qualified name` of the function (at TOS) """ However, this doesn't capture the fact that: * if there are annotations, the number of default arguments returned by `argc & 0xFF` must be reduced by `(argc >> 16) & 0x7FFF` * The value `(argc >> 16) & 0x7FFF` for the number of annotations *includes* the "extra" entry for the tuple describing which arguments the annotations apply to. This means that `(argc >> 16) & 0x7FFF` will be either 0, or 2+; it can't be 1 (because if you have one annotation, you must also have a tuple describing which arguments is annotated). ---------- assignee: docs@python components: Documentation messages: 256189 nosy: docs@python, freakboy3742 priority: normal severity: normal status: open title: Documentation of MAKE_FUNCTION is still incorrect versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25836> _______________________________________

2 3

[issue13677] correct docstring for builtin compile
by Jim Jewett 22 Mar '18

22 Mar '18

New submission from Jim Jewett <jimjjewett(a)gmail.com>: The current docstring for compile suggests that the flags are strictly for selecting future statements. These are not the only flags. It also suggests that the source must be source code and the result will be bytecode, which isn't quite true. I suggest changing: "The flags argument, if present, controls which future statements influence the compilation of the code." to: "The flags argument, if present, largely controls which future statements influence the compilation of the code. (Additional flags are documented in the AST module.)" ---------- assignee: docs@python components: Documentation files: bltinmodule.c.patch keywords: patch messages: 150337 nosy: Jim.Jewett, docs@python priority: normal severity: normal status: open title: correct docstring for builtin compile type: behavior Added file: http://bugs.python.org/file24105/bltinmodule.c.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13677> _______________________________________

4 6

[issue4819] Misc/cheatsheet needs updating
by Serhiy Storchaka 22 Mar '18

22 Mar '18

Change by Serhiy Storchaka <storchaka+cpython(a)gmail.com>: ---------- status: open -> pending versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue4819> _______________________________________

1 0

[issue15248] Better explain "TypeError: 'tuple' object is not callable"
by Serhiy Storchaka 22 Mar '18

22 Mar '18

Serhiy Storchaka <storchaka+cpython(a)gmail.com> added the comment: Actually the precedence was a warning for an assert like: assert(x % 2 == 0, "x is odd") Currently it is the only syntax warning produced by the compiler. > 1. Why 'chech' instead of 'check'? Just a typo replicated with a copy-paste. > 2. Will chech_index catch "[1,2] [3,4]"? (I am guessing that is the intent.) Yes, it is. It could be extended to catch also "['foo','bar'] ['baz']". > 3. Does Syntax Warning stop compilation, or at least execution, as at a >>> prompt? No, it is just a warning unless you run Python with -Werror. This patch was inspired by usability improvements in GCC 8 [1]. I haven't created a pull request because I have doubts about that this should be in the compiler rather of a third-party linter. But if several other core developers will support this idea I'll continue working in this direction. [1] https://developers.redhat.com/blog/2018/03/15/gcc-8-usability-improvements/ ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue15248> _______________________________________

1 0

[issue15248] Better explain "TypeError: 'tuple' object is not callable"
by Terry J. Reedy 22 Mar '18

22 Mar '18

Terry J. Reedy <tjreedy(a)udel.edu> added the comment: Reviewing Serhiy's patch, I changed my mind from 6 years ago (msg164774). I may have over-estimated the difficulty; in any case the code patch is written. (Tests are still needed.) And the code is rather straightforward and readable. Beyond that, I see the patch as detecting a SyntaxError during compilation, as explained below, with the hint being frosting on top of that. (It is not an 'Error' as the grammar is now, but it is an error as we might like it to be, hence Serhiy used SyntaxWarning instead.) In addition, we now have the 'print' precedent of 'print'. >>> print 1 SyntaxError: Missing parentheses in call to 'print'. Did you mean print(1)? I don't remember when this was added, but I don't see any mention above. And it seems from other discussions, like the recent python-ideas thread about possibly deprecating 'string' 'joining', that several people have much more of a problem with missing commas than some of us do. If it were possible, we would like the 'call' production to be call ::= callable "(" [argument_list [","] | comprehension] ")" but 'callable' is not syntactically definable. What is syntactically definable and what Serhiy's patch implements is possible_callable ::= primary - <obvious exclusions> call ::= possible_callable ... As it happens, our grammar metasyntax does not (I believe) include set difference, and I suspect that implementing 'possible_callable' by set addition would result in something that is not LL(1) and possibly ambiguous. Even if 'possible_callable' could be defined within the LL(1) constraint, I suspect it would be messy, and special-casing would still be needed for the special-case message. Ditto for 'possibly_subscriptable'. I have 3 questions: 1. Why 'chech' instead of 'check'? 2. Will chech_index catch "[1,2] [3,4]"? (I am guessing that is the intent.) 3. Does Syntax Warning stop compilation, or at least execution, as at a >>> prompt? Aside from that, I would be inclined to mark this for 'Interpreter Core' and seriously consider it. ---------- versions: +Python 3.8 -Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue15248> _______________________________________

1 0

[issue15248] Better explain "TypeError: 'tuple' object is not callable"
by Serhiy Storchaka 21 Mar '18

21 Mar '18

Change by Serhiy Storchaka <storchaka+cpython(a)gmail.com>: ---------- keywords: +patch Added file: https://bugs.python.org/file47496/compile-warnings.diff _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue15248> _______________________________________

1 0

[issue15248] Better explain "TypeError: 'tuple' object is not callable"
by Serhiy Storchaka 21 Mar '18

21 Mar '18

Serhiy Storchaka <storchaka+cpython(a)gmail.com> added the comment: It is possible to make the compiler producing warnings for such kind of errors. The following sample patch does this. I'm not sure it is worth to do. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue15248> _______________________________________

1 0

email.header examples
by Filip Valder 21 Mar '18

21 Mar '18

Hi all. I would like to request documentation changes for code examples in: https://docs.python.org/2/library/email.header.html https://docs.python.org/3/library/email.header.html Please see below & change it as desired or discard completely if it is unwanted. The main point is that people who are not familiar with mail headers format actually use otherwise working examples from the docs and they do not know that the headers would be formatted inappropriately (in Python 3). The fix below is still not yet complete, as optimal would be adding: header_name='Subject' to the params when creating the Header. Still it (at least) covers the main/significant difference between the two Python versions. For Python 2 - add .encode() method and the comment: >>> msg['Subject'] = h Change to: >>> msg['Subject'] = h.encode() # .encode() ensures same behavior when >>> # porting code to Python 3 For Python 3 - just add the .encode() method: >>> msg['Subject'] = h Change to: >>> msg['Subject'] = h.encode() Regards, thank you, Filip -- Filip Valder EMEA Software Engineer +420 532 270 041 fvalder(a)redhat.com Red Hat Czech Purkyňova 71/99, 3080/97b, 647/111 612 00, Brno (CZ)

1 0

[issue18802] ipaddress documentation errors
by Xiang Zhang 21 Mar '18

21 Mar '18

Change by Xiang Zhang <angwerzx(a)126.com>: ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue18802> _______________________________________

1 0