Mailman 3 May 2016 - docs

[issue27037] Universal newline support for zipFile.ZipExtFile.read() is not working (deprecated?), and the missing functionality not documented
by R. David Murray May 16, 2016

May 16, 2016

Changes by R. David Murray <rdmurray(a)bitdance.com>: ---------- Removed message: http://bugs.python.org/msg265705 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue27037> _______________________________________

1 0

[issue27037] Universal newline support for zipFile.ZipExtFile.read() is not working (deprecated?), and the missing functionality not documented
by R. David Murray May 16, 2016

May 16, 2016

R. David Murray added the comment: The decision was to deprecate 'U' *everywhere* in python3. Yes, the 2.7 method you are concerned about is broken with respect to its documentation, which is what #6759 was about originally. That issue was deemed too disruptive to the codebase to address effectively, but in fixing things properly for python3 we apparently lost track of the 2.7 bug. You can fix the problem (in a forward compatible way) by wrapping the ZipExtFile in an io.TextIOWrapper. The 2.7 documentation should be changed to address this issue and the solution. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue27037> _______________________________________

1 0

[issue27037] Universal newline support for zipFile.ZipExtFile.read() is not working (deprecated?), and the missing functionality not documented
by R. David Murray May 16, 2016

May 16, 2016

R. David Murray added the comment: The decision was to deprecate 'U' *everywhere* in python3. Yes, the 2.7 method you are concerned about is broken with respect to its documentation, which is what #6759 was about originally. That issue was deemed too disruptive to the codebase to address effectively, but in fixing things propery for python3 we apparently lost track of the 2.7 bug. You can fix the problem (in a forward compatible way) by wrapping the ZipExtFile in an io.TextIOWrapper. The 2.7 documentation should be changed to address this issue and the solution. ---------- assignee: -> docs@python components: +Documentation -Library (Lib) nosy: +docs@python, r.david.murray _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue27037> _______________________________________

1 0

Mark up of references in different form (issue 27036)
by vadmium+py＠gmail.com May 16, 2016

May 16, 2016

https://bugs.python.org/review/27036/diff/17256/Doc/library/asyncore.rst File Doc/library/asyncore.rst (right): https://bugs.python.org/review/27036/diff/17256/Doc/library/asyncore.rst#ne… Doc/library/asyncore.rst:104: :c:func:`polled <poll>` for read and write events. Would it hurt to just drop the markup? As far as I know it normally just changes the font, and doesn’t make a link. https://bugs.python.org/review/27036/diff/17256/Doc/library/email.headerreg… File Doc/library/email.headerregistry.rst (right): https://bugs.python.org/review/27036/diff/17256/Doc/library/email.headerreg… Doc/library/email.headerregistry.rst:214: ``decoded`` value is set by :attr:`joining <~str.join>` the :class:`str` value of I think you would have to drop the tilde (~) to get the link to work. There are other changes that also have this problem. But I don’t like this version any better than the original. What about something like: . . . is set to the concatenation of the :class:`str` value of each element . . ., using :meth:`str.join` and a separator of ``', '``. https://bugs.python.org/review/27036/diff/17256/Doc/whatsnew/3.4.rst File Doc/whatsnew/3.4.rst (right): https://bugs.python.org/review/27036/diff/17256/Doc/whatsnew/3.4.rst#newcod… Doc/whatsnew/3.4.rst:1116: mmap objects can now be :mod:`weakrefed <weakref>`. (Contributed by Valerie Lambert in Should probably be spelt “weakreffed” (refed means re-fed as in fed again) Maybe “weakly referenced with :mod:`weakref` ”, or similar? https://bugs.python.org/review/27036/

1 0

[issue18531] Undocumented different between METH_KEYWORDS and **kws
by Barry A. Warsaw May 16, 2016

May 16, 2016

New submission from Barry A. Warsaw: A colleague discovered an interesting implementation different between C-defined functions and Python-defined functions called with **kws arguments. He tried to do this: >>> from collections import defaultdict >>> '{foo}{bar}'.format(**defaultdict(str)) '' He wondered how this could work, especially given: >>> def what(**kws): ... print(type(kws), repr(kws)) ... >>> what(**defaultdict(str)) <class 'dict'> {} The Language Reference clearly states that when what() is called, a new dictionary is create, which is populated by keyword arguments not consumed by positional args. http://docs.python.org/3/reference/compound_stmts.html#function-definitions http://docs.python.org/3/reference/expressions.html#calls What isn't described is the behavior when the function is defined in C using METH_KEYWORDS. In that case, the object passed through the ** argument is passed unscathed to the underlying methodobject defined to take METH_KEYWORDS. str.format() is of the latter type so it gets the actual defaultdict. what() of course gets the defined behavior. It would be nice if the implementation details of the function did not leak into this behavior, but this is admittedly a corner case of the CPython implementation. I haven't checked any of the alternative implementations to see what they do. My guess is that CPython won't change for practical and backward compatibility reasons, thus I've opened this issue as a documentation bug. At the very least, an implementation note in the Language Reference should be added. ---------- assignee: docs@python components: Documentation messages: 193559 nosy: barry, docs@python priority: normal severity: normal status: open title: Undocumented different between METH_KEYWORDS and **kws versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18531> _______________________________________

6 18

[issue27023] Documentation of tempfile.gettempdir() does not mention it only supports existing directories
by ProgVal May 15, 2016

May 15, 2016

New submission from ProgVal: Documentation of tempfile.gettempdir() <https://docs.python.org/3/library/tempfile.html#tempfile.gettempdir> does not mention it only supports existing directories. This led to this question on Stackoverflow: http://stackoverflow.com/q/37229398/539465 ---------- assignee: docs@python components: Documentation, Library (Lib) messages: 265539 nosy: Valentin.Lorentz, docs@python priority: normal severity: normal status: open title: Documentation of tempfile.gettempdir() does not mention it only supports existing directories versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue27023> _______________________________________

3 5

[issue27018] Incorrect documentation of select module
by Salvo “LtWorf” Tomaselli May 15, 2016

May 15, 2016

New submission from Salvo “LtWorf” Tomaselli: import select help(select.epoll) It mentions that the default mask is EPOLL_IN | EPOLL_OUT | EPOLL_PRI. However there are no such constants. They are called EPOLLIN EPOLLOUT and EPOLLPRI. Please fix. ---------- assignee: docs@python components: Documentation messages: 265513 nosy: Salvo “LtWorf” Tomaselli, docs@python priority: normal severity: normal status: open title: Incorrect documentation of select module versions: Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue27018> _______________________________________

4 3

[issue2675] Curses terminal resize problems when Python is in interactive mode
by Martin Panter May 15, 2016

May 15, 2016

Martin Panter added the comment: For the record, this is my interpretation of Pavel’s demo: If you press a key (other than lowercase “q”) or resize the terminal, it displays the terminal dimensions in the top-left corner. Without Readline, the dimensions are updated when the terminal resizes. When Readline is used (interactive mode, or simply “import readline”), the reported dimensions are static, which I understand is the bug. Documentating this quirk may be a good start. ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python, martin.panter stage: test needed -> needs patch versions: +Python 2.7, Python 3.5, Python 3.6 -Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue2675> _______________________________________

1 0

[issue1705393] Document select() failure with buffered file
by Martin Panter May 14, 2016

May 14, 2016

Changes by Martin Panter <vadmium+py(a)gmail.com>: ---------- title: Select() failure (race condition) -> Document select() failure with buffered file versions: +Python 3.5, Python 3.6 -Python 3.1, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue1705393> _______________________________________

1 0

How do I install an interpreter?
by Slater, John May 12, 2016

May 12, 2016

Hello, I'm in a bit of a pickle, so this is both a request and a doc bug report (possibly). Full disclosure: I can't code my way out of a wet paper bag. I've been given a somewhat critical python script to run on my windows box. I found this: https://docs.python.org/2/faq/windows.html And I got to the step where it says: You should then see something like: Python 2.7.3 (default, Apr 10 2012, 22.71:26) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> Well, I don't see that. So I'm guessing an interpreter isn't installed. Where do I get one? Additionally: I would suggest your documentation needs a fork there that says: "Don't see something like this? Click here" Just a helpful suggestion from a lost n00b. Also, if you could get me some help on where to get an interpreter, that would be great too. Thanks! John

2 1