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>
_______________________________________
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>
_______________________________________
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>
_______________________________________
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>
_______________________________________
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>
_______________________________________