docs December 2014

docs@python.org

39 participants
553 discussions

[issue23005] typos on heapq doc
by Ned Deily 07 Dec '14

07 Dec '14

Changes by Ned Deily <nad(a)acm.org>: ---------- assignee: -> docs@python components: +Documentation -Library (Lib) nosy: +docs@python -ned.deily versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23005> _______________________________________

1 0

Re: [docs] There is no standard TestCase.runTest implementation (issue 22153)
by berker.peksag＠gmail.com 06 Dec '14

06 Dec '14

LGTM. http://bugs.python.org/review/22153/diff/13362/Doc/library/unittest.rst File Doc/library/unittest.rst (right): http://bugs.python.org/review/22153/diff/13362/Doc/library/unittest.rst#new… Doc/library/unittest.rst:1561: A test case instance is created for each method named by This part does not apply to the correct place: $ hg imp --no-c http://bugs.python.org/file37372/runtest.patch applying http://bugs.python.org/file37372/runtest.patch patching file Doc/library/unittest.rst Hunk #2 succeeded at 1554 with fuzz 2 (offset -6 lines). applied to working directory And here is the output of "hg diff": :class:`TestLoader` objects have the following attributes: + A test case instance is created for each method named by + :meth:`getTestCaseNames`. By default these are the method names + beginning with *test*. If :meth:`getTestCaseNames` returns no methods, + but the :meth:`runTest` method is implemented, a single test case is + created for that method instead. .. attribute:: errors http://bugs.python.org/review/22153/diff/13362/Doc/library/unittest.rst#new… Doc/library/unittest.rst:1563: beginning with *test*. If :meth:`getTestCaseNames` returns no methods, *test* -> ``test`` http://bugs.python.org/review/22153/

1 0

[issue22998] inspect.Signature and default arguments
by R. David Murray 06 Dec '14

06 Dec '14

R. David Murray added the comment: I'm good with your solution, but I'm going to adjust the resolution by changing the component :) ---------- assignee: -> docs@python components: +Documentation -Library (Lib) nosy: +docs@python resolution: wont fix -> fixed stage: -> resolved _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22998> _______________________________________

1 0

[issue22581] Other mentions of the buffer protocol
by Serhiy Storchaka 05 Dec '14

05 Dec '14

New submission from Serhiy Storchaka: In addition to issue16518. There are other non-fixed messages (may be introduced after 3.3): >>> b''.join(['']) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: sequence item 0: expected bytes, bytearray, or an object with the buffer interface, str found >>> str(42, 'utf8') Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: coercing to str: need bytes, bytearray or buffer-like object, int found >>> import array; array.array('B').frombytes(array.array('I')) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: string/buffer of bytes required. >>> import socket; print(socket.socket.sendmsg.__doc__) sendmsg(buffers[, ancdata[, flags[, address]]]) -> count Send normal and ancillary data to the socket, gathering the non-ancillary data from a series of buffers and concatenating it into a single message. The buffers argument specifies the non-ancillary data as an iterable of buffer-compatible objects (e.g. bytes objects). The ancdata argument specifies the ancillary data (control messages) as an iterable of zero or more tuples (cmsg_level, cmsg_type, cmsg_data), where cmsg_level and cmsg_type are integers specifying the protocol level and protocol-specific type respectively, and cmsg_data is a buffer-compatible object holding the associated data. The flags argument defaults to 0 and has the same meaning as for send(). If address is supplied and not None, it sets a destination address for the message. The return value is the number of bytes of non-ancillary data sent. And there are several mentions of "buffer-like" or "buffer-compatible" in the documentation. ---------- assignee: docs@python components: Documentation keywords: easy messages: 228799 nosy: chris.jerdonek, docs@python, eric.araujo, ezio.melotti, flox, georg.brandl, pitrou, python-dev, r.david.murray, rhettinger, serhiy.storchaka, skrah, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Other mentions of the buffer protocol _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22581> _______________________________________

5 14

[issue22394] Update documentation building to use venv and pip
by Brett Cannon 05 Dec '14

05 Dec '14

New submission from Brett Cannon: Now that we have ensurepip, is there any reason to not have the Doc/ Makefile create a venv for building the docs instead of requiring people to install sphinx into either their global Python interpreter or some venv outside of their checkout? Basically it would be like going back to the old Makefile of checking out the code but instead do a better isolation job and let pip manage fetching everything, updating the projects, etc. ---------- assignee: docs@python components: Documentation messages: 226821 nosy: brett.cannon, docs@python priority: low severity: normal stage: needs patch status: open title: Update documentation building to use venv and pip type: enhancement versions: Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22394> _______________________________________

4 7

Other mentions of the buffer protocol (issue 22581)
by rdmurray＠bitdance.com 05 Dec '14

05 Dec '14

http://bugs.python.org/review/22581/diff/13303/Doc/c-api/arg.rst File Doc/c-api/arg.rst (right): http://bugs.python.org/review/22581/diff/13303/Doc/c-api/arg.rst#newcode73 Doc/c-api/arg.rst:73: ``s*`` (:class:`str`, :class:`bytes`, :class:`bytearray` or :term:`bytes-like object`) [Py_buffer] bytes and bytearray are bytes-like object, so wouldn't it be better to just say :class:`str` or :term:`bytes-like object`? http://bugs.python.org/review/22581/diff/13303/Doc/c-api/arg.rst#newcode79 Doc/c-api/arg.rst:79: ``s#`` (:class:`str`, :class:`bytes` or read-only :term:`bytes-like object`) [const char \*, int or :c:type:`Py_ssize_t`] again, drop :class:`bytes`? Or, since 'read-only' is a restriction on bytes-like object that I don't think is covered in the description of the term, perhaps it should say "read-only :term:`bytes-like object` such as :class:`bytes`". http://bugs.python.org/review/22581/diff/13303/Doc/c-api/arg.rst#newcode90 Doc/c-api/arg.rst:90: ``z*`` (:class:`str`, :class:`bytes`, :class:`bytearray`, :term:`bytes-like object` or ``None``) [Py_buffer] as above http://bugs.python.org/review/22581/diff/13303/Doc/c-api/arg.rst#newcode94 Doc/c-api/arg.rst:94: ``z#`` (:class:`str`, :class:`bytes`, read-only :term:`bytes-like object` or ``None``) [const char \*, int] as above http://bugs.python.org/review/22581/diff/13303/Doc/c-api/arg.rst#newcode98 Doc/c-api/arg.rst:98: ``y`` (:class:`bytes` or read-only :term:`bytes-like object`) [const char \*] as above http://bugs.python.org/review/22581/diff/13303/Doc/c-api/arg.rst#newcode104 Doc/c-api/arg.rst:104: ``y*`` (:class:`bytes`, :class:`bytearray` or :term:`bytes-like object`) [Py_buffer] as above http://bugs.python.org/review/22581/diff/13303/Doc/c-api/arg.rst#newcode109 Doc/c-api/arg.rst:109: ``y#`` (:class:`bytes` or read-only :term:`bytes-like object`) [const char \*, int] as above http://bugs.python.org/review/22581/diff/13303/Doc/library/socket.rst File Doc/library/socket.rst (right): http://bugs.python.org/review/22581/diff/13303/Doc/library/socket.rst#newco… Doc/library/socket.rst:1126: non-ancillary data as an iterable of bytes-like objects missing :term: http://bugs.python.org/review/22581/

1 0

[issue22987] ssl module documentation: incorrect compatibility matrix
by Kali Kaneko 04 Dec '14

04 Dec '14

New submission from Kali Kaneko: The SSLv23 row that can be read in the socket creation section in the documentation for the ssl module looks incorrect: https://docs.python.org/2.7/library/ssl.html#socket-creation by my tests (with python 2.7.8) that row should read: yes no yes yes yes yes instead of: yes no yes no no no as it does now. Since a client specifying SSLv23 should be (and it seems to be) able to negotiate the highest available version that the server can offer, no matter if the server has chosen a tls version. Is this an error in the documentation, or is there any situation in which the current values hold true? ---------- assignee: docs@python components: Documentation messages: 232078 nosy: docs@python, kali priority: normal severity: normal status: open title: ssl module documentation: incorrect compatibility matrix versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22987> _______________________________________

4 5

Re: [docs] os.popen & os.system lack shell-related security warnings (issue 21557)
by pybugs＠rebertia.com 03 Dec '14

03 Dec '14

http://bugs.python.org/review/21557/diff/13339/Doc/library/os.rst File Doc/library/os.rst (right): http://bugs.python.org/review/21557/diff/13339/Doc/library/os.rst#newcode29… Doc/library/os.rst:2913: For greater safety, consider using :mod:`subprocess` with On 2014/12/03 19:05:13, demian wrote: > This should point to subprocess.Popen > (https://docs.python.org/2/library/subprocess.html#subprocess.Popen) rather than > the module, no? The subprocess module's convenience functions (subprocess.call(), etc.) are also reasonable alternatives, so I just referred to the entire subprocess module generally. http://bugs.python.org/review/21557/

1 0

[issue22988] No error when yielding from `finally`
by Guido van Rossum 03 Dec '14

03 Dec '14

Changes by Guido van Rossum <guido(a)python.org>: ---------- nosy: -gvanrossum _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22988> _______________________________________

1 0

[issue22988] No error when yielding from `finally`
by Felipe 03 Dec '14

03 Dec '14

Felipe added the comment: Thanks for the clarification; sorry I misread issue #14718. I agree with Ethan's point. Though I would say "Yield expressions are allowed anywhere in try ... except ... finally constructs." I'd also like to explicitly add a point about the exception-handling machinery getting frozen, but I'm not sure how to phrase it clearly and accurately. Here's an attempt (my adds in square brackets): "By suspended, we mean that all local state is retained, including the current bindings of local variables, the instruction pointer, the internal evaluation stack, [active exception handlers, and paused exceptions in finally blocks]." Another approach would be: "By suspended, we mean that all local state is retained, including the current bindings of local variables, the instruction pointer, and the internal evaluation stack. [The state of any exception-handling code is also retained when yielding from a try ... except ... finally statement.]" ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22988> _______________________________________

1 0

Jump to page:

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

docs December 2014