> >> 2. There is no way for a consumer to tell the protocol-exporting >>object it is "finished" with its view of the memory and therefore no way >>for the object to be sure that it can reallocate the pointer to the >>memory that it owns (the array object reallocating its memory after >>sharing it with the buffer object led to the infamous buffer-object >>problem). > > > I'm a bit worried about having a get/release kind of thing > in the protocol, because it risks forcing all objects which > implement the protocol to provide some kind of refcounting > and locking mechanism for their data. Some objects may not > be able to do that easily or efficiently, especially if > they're wrapping some external library that has no such > notion.
If they can't do it easily, then they don't have to define the release-function and Python will never call it. > > >>All that is needed is to create a Python "memory_view" object that can >>contain all the information needed and be returned when the buffer >>protocol is called --- when it is garbage-collected, the >>"bp_release_view" function is called on the exporting object. > > > That sounds too heavyweight. Getting a memory view through > this protocol should be a very lightweight operation -- ideally > it shouldn't require allocating any memory at all, and it > certainly shouldn't require creating a Python object. If you want shape information you are going to have to allocate memory. If you are going to do that you might as well return a Python object so you can manage this memory easily. If you don't want or need shape or detailed type information, I could also see and have no objection to keeping a lightweight version of the protocol that only returns simple integers. I'll put that in the PEP. -Travis _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
