On Fri, Sep 21, 2012 at 1:16 AM, Glyph <glyph at twistedmatrix.com> wrote: > Le Sep 20, 2012 à 11:35 AM, David Beazley <dave at 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 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 ;-). > > -g 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. Cheers, fijal
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4