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 skrah
Recipients gregory.p.smith, jcon, mark.dickinson, ncoghlan, pitrou, skrah, teoliphant, vstinner, xuanji
Date 2011-08-23.16:27:03
SpamBayes Score 7.9315505e-08
Marked as misclassified No
Message-id <20110823162420.GA16027@sleipnir.bytereef.org>
In-reply-to <1314112959.68.0.451269179975.issue5231@psf.upfronthosting.co.za>
Content
Nick Coghlan <report@bugs.python.org> wrote:
> So I agree with Victor that 1-D bytes -> any shape/format and any
> shape/format -> 1-D bytes should be allowed, but I think we should
> hold off on allowing arbitrary transformations in a single step.

1-D bytes -> any shape/format would work if everyone agrees on the
Numpy mailing list post that I linked to in an earlier message.

[Summary: PyBUF_SIMPLE may downcast any C-contiguous array to unsigned bytes.]

Otherwise a PyBUF_SIMPLE getbuffer call to the newly shaped memoryview
would be required to fail, and these calls are almost certain to occur
somewhere, e.g. in PyObject_AsWriteBuffer().

But then memoryview would also need a 'shape' parameter:

m = memoryview(x, format='L', shape=[3, 4])

In that case, making it a method might indeed be more clear to underline
that something extraordinary is going on:

m = memoryview(x).cast(format='L', shape=[3, 4])

It also takes away a potential speed loss for regular uses.

1-D bytes would then be defined as 'b', 'B' and 'c', I presume? Being able
to cast to 'c' would also solve certain memoryview index assignment problems
that arise if we opt for strict typing as the struct module does.
History
Date User Action Args
2011-08-23 16:27:04skrahsetrecipients: + skrah, gregory.p.smith, teoliphant, mark.dickinson, ncoghlan, pitrou, vstinner, xuanji, jcon
2011-08-23 16:27:03skrahlinkissue5231 messages
2011-08-23 16:27:03skrahcreate