[Python-Dev] State of PEP-3118 (memoryview part)

[Stefan Krah]

Terry Reedy <tjreedy at udel.edu> wrote:
>>>> Options 2) and 3) would ideally entail one backwards
>>>> incompatible bugfix: In 2.7 and 3.2 assignment to a memoryview
>>>> with format 'B' rejects integers but accepts byte objects, but
>>>> according to the struct syntax mandated by the PEP it should be
>>>> the other way round.
>
> If implementation and PEP conflict, the normal question is 'what does  
> the doc say?' as doc takes precedent over PEP. However, in this case the  
> 'MemoryView objects' section under 'Concrete objects' says nothing about  
> the above that I could see and refers to Buffer Protocal in Abstract  
> Objects Layer. I did not see anything there either, but could have  
> missed it.

For the C-API, it's here:

http://docs.python.org/py3k/c-api/buffer.html#the-buffer-structure

const char *format

  A NULL terminated string in struct module style syntax giving the
  contents of the elements available through the buffer. If this is NULL,
  "B" (unsigned bytes) is assumed.


Unfortunately, the memoryview documentation itself gives examples
like these:

http://docs.python.org/py3k/library/stdtypes.html#typememoryview

data = bytearray(b'abcefg')
v = memoryview(data)
v[0] = b'z' # That's where the struct module would throw an error.


> * 3.2.3 is, I presume, less than a month away, and if that is missed,  
> the next and last bugfix will be 3.2.4 at about the same time as 3.3.0.  

That would be too soon indeed.


> * As for porting, my impression is that the PEP directly affects only C
> code and Python code using ctypes and only some fraction of those. If
> the bugfix-only patch is significantly different from complete patch,
> porting to 3.2 would be significantly different from porting to 3.3. So
> I can foresee a temptation to just port to 3.3 anyway.

The general problem is this: If someone supports 2 and 3 and uses the
single codebase approach, it's unlikely that new features will ever be
used. Even if a new 3.3 project is started that needs to be backwards
compatible, I can imagine that people will shun anything that 3to2 isn't
able to handle (out of the box).


This would be less of an issue if the officially sanctioned way of porting
were the "separate branches with 2to3 (or 3to2) for the initial conversion"
approach.


Stefan Krah