This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: buffer() object broken.
Type: Stage:
Components: Interpreter Core Versions: Python 2.4
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: nascheme Nosy List: nascheme, rjs_org
Priority: normal Keywords:

Created on 2005-06-15 18:17 by rjs_org, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (7)
msg25548 - (view) Author: Ray Schumacher (rjs_org) Date: 2005-06-15 18:17
Same as:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470:

Still broken in 2.4.1...!

C:\projects\temp\fftw>python
ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on
Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import Numeric
>>> i = Numeric.zeros(8)
>>> repr(buffer(i))
'<read-only buffer for 0x008D7200, size -1, offset 0 at
0x008D1B20>'
>>> repr(buffer(""))
'<read-only buffer for 0x0086A038, size -1, offset 0 at
0x008D1B20>'

(Numeric v23.8)
msg25549 - (view) Author: Neil Schemenauer (nascheme) * (Python committer) Date: 2005-06-16 18:49
Logged In: YES 
user_id=35752

Please explain exactly what you think is broken about the
buffer object.
msg25550 - (view) Author: Ray Schumacher (rjs_org) Date: 2005-06-17 17:31
Logged In: YES 
user_id=287034

repr(buffer("")) used to return:
<read-only buffer for 0x0086A038, ptr 0x008D0520, size 1 at 
0x008D1B20>

now returns:
>>> repr(buffer(""))
'<read-only buffer for 0x0086A038, size -1, offset 0 at
0x008D1B20>'

same as:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470
msg25551 - (view) Author: Neil Schemenauer (nascheme) * (Python committer) Date: 2005-06-17 17:52
Logged In: YES 
user_id=35752

The repr of a buffer() object has indeed changed.  I don't
see how that's a bug though.
msg25552 - (view) Author: Ray Schumacher (rjs_org) Date: 2005-06-17 19:04
Logged In: YES 
user_id=287034

In 2.3, the actual adress of the first element of an array
could be parsed for doing a memmove(), and now, not, which
breaks some older code. If this is a "more Pythonic"
feature, then OK; the previous resolution said "Fixed in
bufferobject.c 2.25." without remark. I assumed that it had
been restored to the previous.
I now have:
    ptr = tpcnv[a.typecode()]()
    pythonapi.PyObject_AsReadBuffer(py_object(a), 
                                                       
byref(ptr), 
                                                       
byref(c_int()))
    ptr.refed_array = a
instead of:
    split(repr(buffer(a)))[5][:-1]
to get/use an address with ctypes...
msg25553 - (view) Author: Neil Schemenauer (nascheme) * (Python committer) Date: 2005-06-18 17:26
Logged In: YES 
user_id=35752

Calling PyObject_AsReadBuffer() is the proper way to get the
address.  It should work with older versions of Python as
well.  The buffer() object was changed in 2.4 to no longer
keep a pointer to buffer memory, only the underlying
PyObject.  It would be possible to make the repr look the
same as pre-2.4 Python.  Do you still care?
msg25554 - (view) Author: Ray Schumacher (rjs_org) Date: 2005-06-20 18:11
Logged In: YES 
user_id=287034

No, since we have now used the PyObject_AsReadBuffer(). 

We use ctypes to transfer data returned from an C-API A/D
driver directly to Numeric arrays via address.
History
Date User Action Args
2022-04-11 14:56:11adminsetgithub: 42087
2005-06-15 18:17:22rjs_orgcreate