Nick Coghlan wrote:
I'm fine with exposing a memoryview.buffer_address attribute in 3.4.
What about objects whose buffer address can change
when the buffer isn't locked?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
On Fri, Sep 21, 2012 at 4:12 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Nick Coghlan wrote:
I'm fine with exposing a memoryview.buffer_address attribute in 3.4.
What about objects whose buffer address can change
when the buffer isn't locked?
Managing the lifecycle issues will be up
On Fri, Sep 21, 2012 at 1:16 AM, Glyph gl...@twistedmatrix.com wrote:
Le Sep 20, 2012 à 11:35 AM, David Beazley d...@dabeaz.com a écrit :
Well, if it's supposed to do that, it certainly doesn't work for me in 3.3.
I get a type error about it wanting a ctypes pointer object.Even if this
On Sep 21, 2012, at 4:45 AM, Maciej Fijalkowski wrote:
This is also kind of a problem with PyPy and CFFI, where we actively
discourage people from using C. Passing address as an int sounds like
a very reasonable solution.
I just wanted to add that getting the address as an integer is
I have recently been experimenting with the memoryview() built-in and have come
to believe that it really needs to expose the 'buf' attribute of the underlying
Py_buffer structure as an integer (see PEP 3118). Let me explain.
The whole point of PEP 3118 (as I understand it) is to provide a
2012/9/20 David Beazley d...@dabeaz.com:
I have recently been experimenting with the memoryview() built-in and have
come to believe that it really needs to expose the 'buf' attribute of the
underlying Py_buffer structure as an integer (see PEP 3118). Let me explain.
The whole point of PEP
How? I must be missing something very obvious.
Cheers,
Dave
On Sep 20, 2012, at 11:48 AM, Benjamin Peterson wrote:
2012/9/20 David Beazley d...@dabeaz.com:
I have recently been experimenting with the memoryview() built-in and have
come to believe that it really needs to expose the 'buf'
On 20/09/2012 5:53pm, David Beazley wrote:
How? I must be missing something very obvious.
I would not call it obvious, but you can do
m = memoryview(bytearray(5))
ctypes.addressof(ctypes.c_char.from_buffer(m))
149979304
However, this only works for writable memoryviews. For
David Beazley d...@dabeaz.com wrote:
I have recently been experimenting with the memoryview() built-in and have
come to believe that it really needs to expose the 'buf' attribute of the
underlying Py_buffer structure as an integer (see PEP 3118). Let me explain.
That sounds quite harmless.
2012/9/20 David Beazley d...@dabeaz.com:
How? I must be missing something very obvious.
If you have some ctypes function that requires a pointer and you pass
a memoryview, ctypes should pass the pointer to the raw memory, right?
--
Regards,
Benjamin
Well, if it's supposed to do that, it certainly doesn't work for me in 3.3. I
get a type error about it wanting a ctypes pointer object.Even if this
worked, it still doesn't address the need to get the pointer value possibly for
some other purpose such as handling it off to a bunch of code
Le Sep 20, 2012 à 11:35 AM, David Beazley d...@dabeaz.com a écrit :
Well, if it's supposed to do that, it certainly doesn't work for me in 3.3.
I get a type error about it wanting a ctypes pointer object.Even if this
worked, it still doesn't address the need to get the pointer value
A memory address is a number. I think an integer is fine--if you're working
at this level, you're already on your own and expected to know what you're
doing. I'd prefer to just get the raw address without yet another level of
indirection.
Other parts of the library already do this. For
On Fri, Sep 21, 2012 at 9:37 AM, David Beazley d...@dabeaz.com wrote:
A memory address is a number. I think an integer is fine--if you're working
at this level, you're already on your own and expected to know what you're
doing. I'd prefer to just get the raw address without yet another
14 matches
Mail list logo
