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 instance array.buffer_info().
Sent from cell
On Sep 20, 2012, at 6:16 PM, Glyph firstname.lastname@example.org wrote:
Le Sep 20, 2012 à 11:35 AM, David Beazley email@example.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 possibly for some other purpose such as handling it off to a bunch of code generated via LLVM.
It seems like there's no reason to need to get the pointer value out as a Python integer. If you are trying to get a pointer from a memoryview into some C code, or into some LLVM generated code, you still need to do the Python int object → C integer-of-some-kind → C pointer type conversion. Better to just go straight from Python memoryview object → C pointer in one supported API call. Isn't this what the y* w* s* format codes are for?
Every time I have something that's a big number and I need to turn it into a pointer, I have to stare at the table in http://en.wikipedia.org/wiki/64_bit#64-bit_data_models for like 30 seconds. I'd rather have some Python API do the staring for me. David, I realize that table is probably permanently visible in the heads-up display that your cybernetic implants afford you, but some of us need to make our way through C code with humbler faculties ;-).