Author pitrou
Recipients kermode, loewis, mark.dickinson, ncoghlan, pitrou, pv, rupole, teoliphant
Date 2011-02-13.04:23:03
SpamBayes Score 1.79707e-07
Marked as misclassified No
Message-id <1297570980.3656.12.camel@localhost.localdomain>
In-reply-to <1297568852.54.0.806337018426.issue10181@psf.upfronthosting.co.za>
Content
Hello,

> I spent today some time to rewrite `memoryobject.c`, and cleaning up
> the Py_buffer handling in it. (I wrote also the Numpy PEP 3118
> implementation, so this was straightforward to do.)

Thanks for trying this.

> - Rewritten memoryobject:
> 
> http://bitbucket.org/pv/cpython-stuff/src/817edc63ce4d/Objects/memoryobject.c

Some worrying things here:

* memoryview_getbuffer() doesn't call the original object's getbuffer.
  This means that if I do:
        m = memoryview(some_object)
        n = memoryview(m)
        m.release()
  n ends up holding a buffer to some_object's memory, but some_object 
  doesn't know about it and can free the pointer at any time.

* same for _get_sub_buffer_index() and _get_sub_buffer_slice0().
  Actually, the whole concept of non-owner memoryviews seems flawed.

* the fact that slicing increments the parent memoryview's refcount 
  means that a loop like:
     while len(m):
       # do something
       m = m[1:]
  will end up keeping N chained memoryviews on the heap. Currently only
  the last memoryview remains alive.

Some other things:

* why do you accept the ellipsis when indexing? what is it supposed to 
  mean?

* please don't use #warning. Just put the TODO in a /* ... */.

* please no "#if PY_VERSION_HEX >= 0x03000000". Just make your source
  py3k-compatible and we'll take care of backporting it to 2.x if your
  patch is accepted ;)
History
Date User Action Args
2011-02-13 04:23:04pitrousetrecipients: + pitrou, loewis, teoliphant, mark.dickinson, ncoghlan, rupole, kermode, pv
2011-02-13 04:23:03pitroulinkissue10181 messages
2011-02-13 04:23:03pitroucreate