On 08/08/2012 11:47, Stefan Krah wrote:
Nick Coghlan wrote:
It does place a constraint on consumers that they can't assume those
fields will be NULL just because they didn't ask for them, but I'm
struggling to think of any reason why a client would actually *check*
that instead of just assuming
Nick Coghlan wrote:
> It does place a constraint on consumers that they can't assume those
> fields will be NULL just because they didn't ask for them, but I'm
> struggling to think of any reason why a client would actually *check*
> that instead of just assuming it.
Can we continue this discussi
- Summary:
The PEP, or sometimes just the documentation, definitely requires that
features not requested shall be NULL.
The API would benefit from:
a. stored flags that tell you the actual structural features.
b. requiring exporters to provide full information (e.g. strides =
{1}, fo
On Sun, Aug 5, 2012 at 2:41 AM, Stefan Krah wrote:
> Nick Coghlan wrote:
>> Think about trying to specify the buffer protocol using only C++
>> references rather than pointers. In Java, it's a lot easier to say
>> "this value must be a reference to 'B'" than it is to say "this value
>> must be NU
Nick Coghlan wrote:
> Think about trying to specify the buffer protocol using only C++
> references rather than pointers. In Java, it's a lot easier to say
> "this value must be a reference to 'B'" than it is to say "this value
> must be NULL". (My Java is a little rusty, but I'm still pretty sure
Serhiy Storchaka wrote:
> 4. The consumer has NOT requested writable buffer, can readonly flag
> of provided buffer be false anyway?
Yes, per the new documentation. This is not explicitly mentioned in the PEP
but was existing practice and greatly simplifies several things:
http://docs.python.org
Nick Coghlan wrote:
> I took Jeff's question as being slightly different and applying in the
> following situations:
I think I attempted to answer the same thing. :)
> 1. If the consumer has NOT requested format data, can the provider
> return accurate format data anyway, if that's easier than
On Sun, Aug 5, 2012 at 1:25 AM, Stefan Krah wrote:
> In most cases it won't matter. However, a consumer is entitled to rely
> on shape==NULL in response to a PyBUF_SIMPLE request. Perhaps there
> is code that tests for shape==NULL to determine C-contiguity.
>
> This is an example that might occur
On 04.08.12 17:51, Nick Coghlan wrote:
I took Jeff's question as being slightly different and applying in the
following situations:
1. If the consumer has NOT requested format data, can the provider
return accurate format data anyway, if that's easier than returning
NULL but is consistent with d
Jeff Allen wrote:
> I still don't see why, if the consumer says "I'm assuming 1-D
> unsigned bytes", and that's what the data is, memoryview_getbuf
> could not provide a shape and strides that agree with the data.
In most cases it won't matter. However, a consumer is entitled to rely
on shape==NU
On Sat, Aug 4, 2012 at 7:11 PM, Stefan Krah wrote:
> You are right that the PEP does not explicitly state that rule for
> strides. However, NULL always has an implied meaning:
>
> format=NULL -> treat the buffer as unsigned bytes.
>
> shape=NULL -> one-dimensional AND treat the buffer as
Thanks for a swift reply: you're just the person I hoped would do so.
On 04/08/2012 10:11, Stefan Krah wrote:
You are right that the PEP does not explicitly state that rule for
strides. However, NULL always has an implied meaning:
format=NULL -> treat the buffer as unsigned bytes.
sha
Jeff Allen wrote:
> I'd like to lay a solid foundation that benefits from the
> recent CPython work. I hope that some of the complexity in
> memoryview stems from legacy considerations I don't have to deal
> with in Jython.
I'm afraid not: PEP-3118 is really that complex. ;)
> My understanding
I'm implementing the buffer API and some of memoryview for Jython. I
have read with interest, and mostly understood, the discussion in Issue
#10181 that led to the v3.3 re-implementation of memoryview and
much-improved documentation of the buffer API. Although Jython is
targeting v2.7 at the mo
14 matches
Mail list logo
