Terry Reedy <tjre...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
