This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients chris.jerdonek, docs@python, eric.araujo, ezio.melotti, pitrou, skrah, terry.reedy
Date 2012-11-23.21:57:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1353707804.3343.9.camel@localhost.localdomain>
In-reply-to <20121123215415.GA3655@sleipnir.bytereef.org>
Content
> > Well, we should still write a Python documentation, not a NumPy
> > documentation (on this tracker anyway). Outside of NumPy, there's little
> > use for multi-dimensional objects.
> 
> Ok, but people should not be surprised if their (Python) array.array() of
> double or their array of ctypes structs is silently accepted by some byte
> consuming function.

Probably. My own (humble :-)) opinion is that array.array() is a
historical artifact, and its use doesn't seem to be warranted in modern
Python code. ctypes is obviously a very special library, and not for the
faint of heart.

> How about "object does not provide a byte buffer" for error messages
> and "(byte) buffer provider" as a shorthand for "any buffer provider
> that exposes its memory as a sequence of unsigned bytes in response
> to a PyBUF_SIMPLE request"?

It's not too bad, I think. However, what I think is important is that
the average (non-expert) Python developer understand that the function
really accepts a bytes object, and other similar types (because, really,
bytes is the only bytes-like type most developers will ever face).
That's why I'm proposing "bytes-like object".
History
Date User Action Args
2012-11-23 21:57:42pitrousetrecipients: + pitrou, terry.reedy, ezio.melotti, eric.araujo, skrah, chris.jerdonek, docs@python
2012-11-23 21:57:42pitroulinkissue16518 messages
2012-11-23 21:57:41pitroucreate