Re: [Python-Dev] Understanding the buffer API
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 is this: When a consumer requests a buffer from the > exporter it specifies using flags how it intends to navigate it. If > the buffer actually needs more apparatus than the consumer proposes, > this raises an exception. If the buffer needs less apparatus than > the consumer proposes, the exporter has to supply what was asked > for. For example, if the consumer sets PyBUF_STRIDES, and the > buffer can only be navigated by using suboffsets (PIL-style) this > raises an exception. Alternatively, if the consumer sets > PyBUF_STRIDES, and the buffer is just a simple byte array, the > exporter has to supply shape and strides arrays (with trivial > values), since the consumer is going to use those arrays. Yes. > Is there any harm is supplying shape and strides when they were not > requested? The PEP says: "PyBUF_ND ... If this is not given then > shape will be NULL". It doesn't stipulate that strides will be null > if PyBUF_STRIDES is not given, but the library documentation says > so. suboffsets is different since even when requested, it will be > null if not needed. 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 unsigned bytes. strides=NULL -> C-contiguous I think relaxing the NULL rule for strides would complicate things, since it would introduce yet another special case. > Similar, but simpler, the PEP says "PyBUF_FORMAT ... If format is > not explicitly requested then the format must be returned as NULL > (which means "B", or unsigned bytes)". What would be the harm in > returning "B"? Ah, yes. The key here is this: "This would be used when the consumer is going to be checking for what 'kind' of data is actually stored." Conversely, if not requested, format=NULL indicates that the real format may be e.g. 'L', but the consumer wants to treat the buffer as unsigned bytes. This works because the 'len' field stores the length of the memory area in bytes (for contiguous buffers at least). The 'itemsize' field may be wrong though in this special case. In general, format=NULL is a cast of a (possibly multi-dimensional) C-contiguous buffer to a one-dimensional buffer of unsigned bytes. IMO only the following combinations make sense. These two are self explanatory: 1) shape=NULL, format=NULL-> e.g. PyBUF_SIMPLE 2) shape!=NULL, format!=NULL -> e.g. PyBUF_FULL 1) can break the invariant product(shape) * itemsize = len! The next combination exists as part of PyBUF_STRIDED: 3) shape!=NULL, format=NULL. It can break two invariants (product(shape) * itemsize = len, calcsize(format) = itemsize), but since it's explicitly part of PyBUF_STRIDED, memoryview_getbuf() allows it. The remaining combination is disallowed, since the buffer is already assumed to be unsigned bytes: 4) shape=NULL, format!=NULL. > One place where this really matters is in the implementation of > memoryview. PyMemoryView requests a buffer with the flags > PyBUF_FULL_RO, so even a simple byte buffer export will come with > shape, strides and format. A consumer (of the memoryview's buffer > API) might specify PyBUF_SIMPLE: according to the PEP I can't simply > give it the original buffer since required fields (that the consumer > will presumably not access) are not NULL. In practice, I'd like to: > what could possibly go wrong? Because of all the implied meanings of NULL, I think the safest way is to implement memoryview_getbuf() for Jython. After all the PEP describes a protocol, so everyone should really be doing the same thing. Whether the protocol needs to be that complex is another question. Partially initialized buffers are a pain to handle on the C level since it is necessary to reconstruct the missing values -- at least if you want to keep your sanity :). I think the protocol would benefit from changing the getbuffer rules to: a) The buffer gets a 'flags' field that can store properties like PyBUF_SIMPLE, PyBUF_C_CONTIGUOUS etc. b) The exporter must *always* provide full information. c) If a buffer can be exported as unsigned bytes but has a different layout, the exporter must perform a full cast so that the above mentioned invariants are kept. The disadvantage of this is that the original layout is lost for the consumer. I do not know if there is a use case that requires the consumer to have the original layout information. Stefan Krah ___ Python-Dev mailing list [email protected] http://mail.python.org/mail
Re: [Python-Dev] Understanding the buffer API
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. shape=NULL -> one-dimensional AND treat the buffer as unsigned bytes. strides=NULL -> C-contiguous I think relaxing the NULL rule for strides would complicate things, since it would introduce yet another special case. ... Ok, I think I see that how the absence of certain arrays is used to deduce structural simplicity, over and above their straightforward use in navigating the data. So although no shape array is (sort of) equivalent to ndim==1, shape[0]==len, it also means I can call simpler code instead of using the arrays for navigation. 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. Is the catch perhaps that there is code (in abstract.c etc.) that does not know what the consumer promised not to use/look at? Would it actually break, e.g. not treat it as bytes, or just be inefficient? Because of all the implied meanings of NULL, I think the safest way is to implement memoryview_getbuf() for Jython. After all the PEP describes a protocol, so everyone should really be doing the same thing. I'll look carefully at what you've written (snipped here) because it is these "consumer expectations" that are most important. The Jython buffer API is necessarily a lot different from the C one: some things are not possible in Java (pointer arithmetic) and some are just un-Javan activities (allocate a struct and have the library fill it in). I'm only going for a logical conformance to the PEP: the same navigational and other attributes, that mean the same things for the consumer. When you say such-and-such is disallowed, but the PEP or the data structures seem to provide for it, you mean memoryview_getbuf() disallows it, since you've concluded it is not sensible? I think the protocol would benefit from changing the getbuffer rules to: a) The buffer gets a 'flags' field that can store properties like PyBUF_SIMPLE, PyBUF_C_CONTIGUOUS etc. b) The exporter must *always* provide full information. c) If a buffer can be exported as unsigned bytes but has a different layout, the exporter must perform a full cast so that the above mentioned invariants are kept. Just like PyManagedBuffer mbuf and its sister view in memoryview? I've thought the same things, but the tricky part is to do it compatibly. a) I think I can achieve this. As I have interfaces and polymorphism on my side, and a commitment only to logical equivalence to CPython, I can have the preserved flags stashed away inside to affect behaviour. But it's not as simple as saving the consumer's request, and I'm still trying to work it out what to do, e.g. when the consumer didn't ask for C-contiguity, but in this case it happens to be true. In the same way, functions you have in abstract.c etc. can be methods that, rather than work out by inspection of a struct how to navigate the data on this call, already know what kind of buffer they are in. So SimpleBuffer.isContiguous(char order) can simply return true. b) What I'm hoping can work, but maybe not. c) Java will not of course give you raw memory it thinks is one thing, to treat as another, so this aspect is immature in my thinking. I got as far as accommodating multi-byte items, but have no use for them as yet. Thanks again for the chance to test my ideas. Jeff Allen ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Understanding the buffer API
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 unsigned bytes. > > strides=NULL -> C-contiguous > > > I think relaxing the NULL rule for strides would complicate things, > since it would introduce yet another special case. 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 doing so? 2. The consumer has NOT requested shape data, can shape data be provided anyway, if that's easier than returning NULL but is consistent with doing so? 3. The consumer has NOT requested strides data, can strides data be provided anyway, if that's easier than returning NULL but is consistent with doing so? That's what I believe is Jeff's main question: is a provider that always publishes complete information, even if the consumer doesn't ask for it, in compliance with the API, so long as any cases where the consumer's stated assumption (as indicated by the request flags) would be violated are handled as errors instead of successfully populating the buffer? Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Understanding the buffer API
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==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 in C. You hinted at the fact that not all of this may be relevant for Java, but on that I can't comment. > When you say such-and-such is disallowed, but the PEP or the data > structures seem to provide for it, you mean memoryview_getbuf() > disallows it, since you've concluded it is not sensible? The particular request of PyBUF_SIMPLE|PyBUF_FORMAT, when applied to any array that is not one-dimensional with format 'B' would lead to a contradiction: PyBUF_SIMPLE implies 'B', but format would be set to something else. It is also a useless combination, since a plain PyBUF_SIMPLE suffices. > >I think the protocol would benefit from changing the getbuffer rules to: > > > >a) The buffer gets a 'flags' field that can store properties like > > PyBUF_SIMPLE, PyBUF_C_CONTIGUOUS etc. > > > >b) The exporter must *always* provide full information. > > > >c) If a buffer can be exported as unsigned bytes but has a different > > layout, the exporter must perform a full cast so that the above > > mentioned invariants are kept. > > > Just like PyManagedBuffer mbuf and its sister view in memoryview? > I've thought the same things, but the tricky part is to do it > compatibly. > > a) I think I can achieve this. As I have interfaces and polymorphism > on my side, and a commitment only to logical equivalence to CPython, > I can have the preserved flags stashed away inside to affect > behaviour. But it's not as simple as saving the consumer's request, > and I'm still trying to work it out what to do, e.g. when the > consumer didn't ask for C-contiguity, but in this case it happens to > be true. > > In the same way, functions you have in abstract.c etc. can be > methods that, rather than work out by inspection of a struct how to > navigate the data on this call, already know what kind of buffer > they are in. So SimpleBuffer.isContiguous(char order) can simply > return true. Avoiding repeated calls to PyBuffer_IsContiguous() was in fact the main reason for storing flags in the new MemoryViewObject. It would be handy to have these flags in the Py_buffer structure, but that can only be considered for a future version of Python, perhaps no earlier than 4.0. The same applies of course to all three points that I made above. Stefan Krah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Understanding the buffer API
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 doing so? 2. The consumer has NOT requested shape data, can shape data be provided anyway, if that's easier than returning NULL but is consistent with doing so? 3. The consumer has NOT requested strides data, can strides data be provided anyway, if that's easier than returning NULL but is consistent with doing so? 4. The consumer has NOT requested writable buffer, can readonly flag of provided buffer be false anyway? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Understanding the buffer API
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 in C. You hinted at the fact that not > all of this may be relevant for Java, but on that I can't comment. 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 you can only get NullPointerException by messing about with the JNI). I think it's worth defining an "OR" clause for each of the current "X must be NULL" cases, where it is legal for the provider to emit an appropriate non-NULL value that would be consistent with the consumer assuming that the returned value is consistent with what they requested. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Understanding the buffer API
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 returning > NULL but is consistent with doing so? No, this is definitely disallowed by the PEP (PyBUF_FORMAT): "If format is not explicitly requested then the format must be returned as NULL (which means "B", or unsigned bytes)." > 2. The consumer has NOT requested shape data, can shape data be > provided anyway, if that's easier than returning NULL but is > consistent with doing so? Also explicitly disallowed (PyBUF_ND): "If this is not given then shape will be NULL." > 3. The consumer has NOT requested strides data, can strides data be > provided anyway, if that's easier than returning NULL but is > consistent with doing so? This is not explicitly disallowed, but IMO the intent is that strides should also be NULL in that case. For example, strides==NULL might be used for a quick C-contiguity test. Stefan Krah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (merge 3.2 -> default): Make TextIOWrapper's documentation clearer by copying the newline argument's
On Fri, Aug 3, 2012 at 3:59 PM, antoine.pitrou wrote: > http://hg.python.org/cpython/rev/f17a1410ebe5 > changeset: 78401:f17a1410ebe5 > summary: > Make TextIOWrapper's documentation clearer by copying the newline > argument's description from open(). Now that this change is made, it may make sense to update the subprocess documentation to reference TextIOWrapper's documentation instead of open()'s (since use of the 'U' flag to open() is discouraged in new code). "All line endings will be converted to '\n' as described for the universal newlines 'U' mode argument to open()." (from http://docs.python.org/dev/library/subprocess.html#frequently-used-arguments ) --Chris ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Understanding the buffer API
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/dev/c-api/buffer.html#PyBUF_WRITABLE Stefan Krah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Understanding the buffer API
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 > you can only get NullPointerException by messing about with the JNI). > > I think it's worth defining an "OR" clause for each of the current "X > must be NULL" cases, where it is legal for the provider to emit an > appropriate non-NULL value that would be consistent with the consumer > assuming that the returned value is consistent with what they > requested. I think any implementation that doesn't use the Py_buffer struct directly in a C-API should just always return a full buffer if a specific request can be met according to the rules. For the C-API, I would be cautious: - The number of case splits in testing getbuffer flags is already staggering. Defining an "OR" clause would introduce new cases. - Consumers may simply rely on the status-quo. As I said in my earlier mail, for Python 4.0, I'd rather see that buffers have mandatory full information. Querying individual Py_buffer fields for NULL should be replaced by a set of flags that would determine contiguity, buffer "history" (has the buffer been cast to unsigned bytes?) etc. It would also be possible to add new flags for things like byte order. The main reason is that it turns out that in any general C function that takes a Py_buffer argument one has to reconstruct full information anyway, otherwise obscure cases *will* be overlooked (in the absence of a formal proof that takes care of all case splits). Stefan Krah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Understanding the buffer API
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 NULL". (My Java is a little rusty, but I'm still pretty sure >> you can only get NullPointerException by messing about with the JNI). >> >> I think it's worth defining an "OR" clause for each of the current "X >> must be NULL" cases, where it is legal for the provider to emit an >> appropriate non-NULL value that would be consistent with the consumer >> assuming that the returned value is consistent with what they >> requested. > > I think any implementation that doesn't use the Py_buffer struct directly > in a C-API should just always return a full buffer if a specific request > can be met according to the rules. Since Jeff is talking about an inspired-by API, rather than using the C API directly, I think that's the way Jython should go: *require* that those fields be populated appropriately, rather than allowing them to be None. > For the C-API, I would be cautious: > >- The number of case splits in testing getbuffer flags is already > staggering. Defining an "OR" clause would introduce new cases. > >- Consumers may simply rely on the status-quo. > > > As I said in my earlier mail, for Python 4.0, I'd rather see that buffers > have mandatory full information. Querying individual Py_buffer fields for > NULL should be replaced by a set of flags that would determine contiguity, > buffer "history" (has the buffer been cast to unsigned bytes?) etc. Making a switch to mandatory full information later suggest that we need to at least make it optional now. I do agree with what you suggest though, which is that, if a buffer chooses to always publish full and accurate information it must do so for *all* fields.Tthat should reduce the combinatorial explosion. 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. I guess the dodgy Py_buffer-copying code in the old memoryview implementation only mostly works because those fields are almost always NULL, but that approach was just deeply broken in general. > The main reason is that it turns out that in any general C function that > takes a Py_buffer argument one has to reconstruct full information anyway, > otherwise obscure cases *will* be overlooked (in the absence of a formal > proof that takes care of all case splits). Right, that's why I think we should declare it legal to *provide* full information even if the consumer didn't ask for it, *as long as* any consumer assumptions implied by the limited request (such as unsigned byte data, a single dimension or C contiguity) remain valid. Consumers that can't handle that correctly (which would likely include the pre-3.3 memoryview) are officially broken. As you say, we likely can't make providing full information mandatory during the 3.x cycle, but we can at least pave the way for it. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (merge 3.2 -> default): Make TextIOWrapper's documentation clearer by copying the newline argument's
2012/8/4 Chris Jerdonek : > On Fri, Aug 3, 2012 at 3:59 PM, antoine.pitrou > wrote: >> http://hg.python.org/cpython/rev/f17a1410ebe5 >> changeset: 78401:f17a1410ebe5 >> summary: >> Make TextIOWrapper's documentation clearer by copying the newline >> argument's description from open(). > > Now that this change is made, it may make sense to update the > subprocess documentation to reference TextIOWrapper's documentation > instead of open()'s (since use of the 'U' flag to open() is > discouraged in new code). > > "All line endings will be converted to '\n' as described for the > universal newlines 'U' mode argument to open()." > > (from > http://docs.python.org/dev/library/subprocess.html#frequently-used-arguments > ) Good idea, can you please open an issue? The documentation is wrong: UTF-8 is not used, it's the locale encoding. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
