Stefan Krah added the comment:
I would commit this, except that I'm not too happy with the use of
the term bytes-like in general. Yesterday I mistyped this:
import ctypes
x = ctypes.c_double
m = memoryview(x)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError:
Antoine Pitrou added the comment:
The thing is, most users don't know what the buffer protocol is (even Numpy
users, probably), while bytes-like at least will make some sense - even
though I agree it's an imperfect approximation.
--
___
Python
Stefan Krah added the comment:
For end users it's probably adequate. But several committers find
the term confusing (msg236283, msg188484). :)
Anyway, I'm going to commit this since it adds clarity.
--
___
Python tracker rep...@bugs.python.org
Roundup Robot added the comment:
New changeset d1ef54751412 by Stefan Krah in branch '3.5':
Issue #23756: Clarify the terms contiguous and bytes-like object.
https://hg.python.org/cpython/rev/d1ef54751412
New changeset c59b2c4f4cac by Stefan Krah in branch 'default':
Merge #23756.
Stefan Krah added the comment:
Martin, thanks for the patch!
--
resolution: - fixed
stage: patch review - resolved
status: open - closed
versions: +Python 3.6 -Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23756
Stefan Krah added the comment:
c-contig.v3.patch LGTM.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23756
___
___
Python-bugs-list mailing
Martin Panter added the comment:
Patch v3:
* Merged with recent changes
* New glossary entry for “contiguous”, with incoming links from various points
* Removed my definition from buffer.rst
I found the Num Py explanation a bit brief, assuming what you quoted was the
extent of it. I used some
Stefan Krah added the comment:
Sorry, I'm still not convinced that the C-contiguity explanation is in the
right place. The docs have to be terse in order to be useful as a reference,
and the explanation at that particular location breaks the flow of reading.
So, please don't commit that.
Changes by Martin Panter vadmium...@gmail.com:
--
stage: needs patch - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23756
___
___
Martin Panter added the comment:
I’m sorry Stefan, I now realize my changes for len(view) were indeed wrong, and
the original was much more correct. I still think the tobytes() and maybe
tolist() documentation could be improved, but that is a separate issue to the
bytes-like definition.
I am
Changes by Stefan Krah ste...@bytereef.org:
--
assignee: docs@python - skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23756
___
___
Stefan Krah added the comment:
If you think that the previous version was incorrect and misleading,
the bar for changes to be accepted seems pretty high for me.
grep -r doesn't seem to find flattened length in Doc/*.
An object that supports the :ref:`bufferobject` and is C-contiguous, like
R. David Murray added the comment:
If a Fortran array was allowed in a bytes-like context without memory
copying, the order of the array elements would differ from the order returned
by the meoryview.tobytes() method, which essentially is defined to copy them
out in C-array or
Stefan Krah added the comment:
I have a somewhat general concern: In the last year or so, issues seem
to expand far beyond the scope that's indicated by the issue title.
For example, I don't particularly care about the definition of
bytes-like, but the patch contains changes to areas I *do*
Serhiy Storchaka added the comment:
+1 for the idea overall and the patch LGTM.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23756
___
___
Martin Panter added the comment:
After doing a bit of reading and experimenting, I think we should at least
restrict bytes-like objects to “C-contiguous”. Any looser definition risks
memoryview(byteslike).tobytes() returning the bytes in a different order than
their true in-memory order.
R. David Murray added the comment:
Oh, and about the general concern: I agree that this issue was apparently about
the glossary entry, so making other changes is suspect and at a minimum
requires adding relevant people from the experts list to nosy to get proper
review of other proposed
R. David Murray added the comment:
I found the explanation of C-contiguous vs Fortran-contiguous helpful (and I've
programmed in both of those languages, though granted not much :). However,
based on that it is not obvious to me why having a fortran-contiguous buffer
prevents it from being
Serhiy Storchaka added the comment:
What people are needed? The patch looks as great improvement to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23756
___
R. David Murray added the comment:
Stefan, since he's the current maintainer of the memoryview implementation.
Fortunately he spotted the issue :) Maybe Antoine, too; he's done work in this
area. I'll add him.
--
nosy: +pitrou
___
Python tracker
Serhiy Storchaka added the comment:
See also issue23376.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23756
___
___
Python-bugs-list mailing
Martin Panter added the comment:
I will to pull the stdtypes.rst changes out into a separate patch and issue, if
that will make review easier. I think they are an improvement because the
previous version was incorrect and misleading, but they are probably not
necessary for people to
Serhiy Storchaka added the comment:
Totally agree. Current definition is too wide. Actually in different places the
term bytes-like object can imply different requirements.
* Supports buffer protocol. list isn't.
* Contiguous. memoryview()[::2] isn't.
* len() returns bytes size. array('I')
R. David Murray added the comment:
This not dissimilar to the problem we have with file like object or file
object. The requirements on them are not consistent. I'm not sure what the
solution is in either case, but for file like objects we have decided to ignore
the issue, I think. (ie:
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +ezio.melotti
stage: - needs patch
type: - enhancement
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23756
___
New submission from Martin Panter:
There are moves at documenting and implementing support for “bytes-like”
objects in more APIs, such as the “io” module (Issue 20699), http.client (Issue
23740). The glossary definition is currently “An object that supports the
Buffer Protocol, like bytes,
26 matches
Mail list logo
