Mailman 3 May 2017 - docs

[issue30358] Profile documentation - include sort argument for runctx
by Cheryl Sabella May 12, 2017

May 12, 2017

Changes by Cheryl Sabella <chekat2(a)gmail.com>: ---------- pull_requests: +1661 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue30358> _______________________________________

1 0

[issue30358] Profile documentation - include sort argument for runctx
by Cheryl Sabella May 12, 2017

May 12, 2017

Changes by Cheryl Sabella <chekat2(a)gmail.com>: ---------- assignee: docs@python components: Documentation nosy: csabella, docs@python priority: normal severity: normal status: open title: Profile documentation - include sort argument for runctx type: enhancement versions: Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue30358> _______________________________________

1 0

question about the documentation
by Samuel Lee Duncan May 11, 2017

May 11, 2017

Your documentation states: In addition to indexing, slicing is also supported. While indexing is used to obtain individual characters, slicing allows you to obtain substring: >>> >>> word[0:2] # characters from position 0 (included) to 2 (excluded) 'Py' >>> word[2:5] # characters from position 2 (included) to 5 (excluded) 'tho' However, for slicing, doesn't it appear to work better if it stated Using 'python' for the word. Word[0:2] # return 2 characters and show me the characters starting at the "0" position - Returns 'py' p is position 0, and py are 2 chars Word[2:5] # return 5 characters and show me the characters starting at the "2" position - Returns 'tho' "o" is the 5th character to be returned (1-based), and "t" is the character at the "2" position (0-based) Word[3:5] # return 5 characters and show me the characters starting at the "3" position - Returns 'ho' "o" is the 5th character to be returned (1-based) and "h" is the character at the "3" position (0-based) Word[5:5] # return 5 characters and show me the characters starting at the "5" position - Returns ' ' - this may be a bug - should throw an error saying the index has been exceeded? Word [4:5] # return 5 characters and show me the characters starting at the "4" position - Returns 'o' - "o" is the 5th character to be returned (1-based) and "o" is the character at the 4th position (0-based) Word[3:4] - Returns 'h' - "h" is the 4th character to be returned (1-based) and "h" is the character at the 3rd position (0-based in the original word 'python') Sincerely, [SamNoManagerSignature]

1 0

[issue30322] PyObject_GetIter does not behave as documented on dict objects
by Sam De Meyer May 10, 2017

May 10, 2017

New submission from Sam De Meyer: According to the docs (https://docs.python.org/3/c-api/object.html) the `PyObject_GetIter` method should be equivalent to the python call `iter(<some_dict>)`, but, when given a dict, the `PyObject_GetIter` returns an iterator over key-value pairs whereas the `iter()` method returns an iterator over keys only. I tripped over this when giving the `<some_dict>.update()` a dict-like object that does not inherit from the builtin dict and implements its own `__iter__()`. The `update()` method eventually reaches the following piece of code: https://hg.python.org/cpython/file/4243df51fe43/Objects/dictobject.c#l2383 > it = PyObject_GetIter(seq2); > ... > item = PyIter_Next(it); > ... > fast = PySequence_Fast(item, ""); > ... > key = PySequence_Fast_GET_ITEM(fast, 0); > value = PySequence_Fast_GET_ITEM(fast, 1); displaying the difference in behaviour between `PyObject_GetIter` and `iter(o)`. ---------- assignee: docs@python components: Documentation messages: 293346 nosy: Sam De Meyer, docs@python priority: normal severity: normal status: open title: PyObject_GetIter does not behave as documented on dict objects versions: Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue30322> _______________________________________

3 3

[issue25409] fnmatch.fnmatch normalizes slashes/backslashes on Windows
by Mariatta Wijaya May 10, 2017

May 10, 2017

Mariatta Wijaya added the comment: Yes, PR 1535 is indeed linked to this issue, if you're reading it from the bug tracker. The pull request number you see from the notification email (+1634) refers to the pull_request item in the bug tracker (https://bugs.python.org/pull_request1634). This number is different than the pull request # on GitHub. Hope this clarifies it :) See also discussions about it: https://github.com/python/core-workflow/issues/35 http://psf.upfronthosting.co.za/roundup/meta/issue624 (I was confused about it too) ---------- nosy: +Mariatta stage: needs patch -> patch review versions: +Python 3.7 -Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25409> _______________________________________

1 0

[issue25409] fnmatch.fnmatch normalizes slashes/backslashes on Windows
by Florian Bruhin May 10, 2017

May 10, 2017

Florian Bruhin added the comment: https://github.com/python/cpython/pull/1535 seems to be the correct PR, not 1634. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25409> _______________________________________

1 0

[issue25409] fnmatch.fnmatch normalizes slashes/backslashes on Windows
by Cheryl Sabella May 10, 2017

May 10, 2017

Changes by Cheryl Sabella <chekat2(a)gmail.com>: ---------- pull_requests: +1634 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25409> _______________________________________

1 0

[issue30307] https://docs.python.org/3/tutorial/introduction.html#strings Section 3.1.2 doc issue
by rohit singh May 9, 2017

May 9, 2017

New submission from rohit singh: The documentation says: >>> '"Isn\'t," she said.' '"Isn\'t," she said.' It should be: >>> '"Isn\'t," she said.' '"Isn't," she said.' ---------- assignee: docs@python components: Documentation messages: 293246 nosy: docs@python, rohit singh priority: normal severity: normal status: open title: https://docs.python.org/3/tutorial/introduction.html#strings Section 3.1.2 doc issue versions: Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue30307> _______________________________________

4 3

[issue10436] tarfile.extractfile in "r|" stream mode fails with filenames or members from getmembers()
by flying sheep May 9, 2017

May 9, 2017

flying sheep added the comment: well, we should just allow extractall(members=['foo', 'bar']) currently members only accepts TarInfo objects, not filenames, but it’s easy to accept both. https://github.com/python/cpython/blob/74683fc6247c522ae955a6e7308b8ff51def… sth like: filenames = set() for member in members: if isinstance(member, TarInfo): # do what’s done now else: filenames.add(member) for tarinfo in self: if tarinfo.name in filenames: self.extract(tarinfo) ---------- nosy: +flying sheep _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10436> _______________________________________

1 0

[issue29956] math.exp documentation is misleading
by Alexander Belopolsky May 8, 2017

May 8, 2017

New submission from Alexander Belopolsky: The math.exp(x) function is documented to "Return e**x" <https://docs.python.org/3/library/math.html#math.exp>. This is misleading because even in the simplest case, math.exp(x) is not the same as math.e ** x: >>> import math >>> math.exp(2) - math.e ** 2 8.881784197001252e-16 I suggest using e<sup>x instead of e**x to distinguish between Python syntax and mathematical operation and change "Return e**x" to "Return e<sup>x, the base-e exponential of x." ---------- assignee: docs@python components: Documentation messages: 290937 nosy: belopolsky, docs@python priority: normal severity: normal status: open title: math.exp documentation is misleading versions: Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29956> _______________________________________

5 23