On 2016-08-11 20:41, Roel Schroeven wrote:
Lawrence D’Oliveiro schreef op 2016-08-10 03:45:
... so WACAH very much applies here.
Pardon my ignorance, but what is the WACAH Principle?
I believe he means "We're All Consenting Adults Here". (I don't think
I've ever seen that acronym before.)
Lawrence D’Oliveiro schreef op 2016-08-10 03:45:
... so WACAH very much applies here.
Pardon my ignorance, but what is the WACAH Principle?
--
The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
-- Isaac Asimov
Roel Schroeven
--
https
On Thursday, August 11, 2016 at 3:23:58 PM UTC+12, eryk sun wrote:
>
> ...you can cast() bytes to c_void_p to get the address.
>
> ...
>
> For bytearray, use the buffer interface to create a ctypes array. The
> array is not a copy.
Cool! Those pointers* are much appreciated.
*So to speak. :)
--
On Wed, Aug 10, 2016 at 10:26 PM, Lawrence D’Oliveiro
wrote:
> But it has to copy the bytes into an array.array object, then decode that. Is
> there a way it
> could access the bytes memory directly?
ctypes cast, string_at, wstring_at, memmove, and memset are
implemented as FFI calls. Since ctyp
On Thursday, August 11, 2016 at 10:31:36 AM UTC+12, Gregory Ewing wrote:
>
> Lawrence D’Oliveiro wrote:
>
>>>It will let you create non-leaky wrappers ...
>>
>> Why would I want to do that?
>
> You mentioned that ctypes wrappers are leaky, which I
> assumed was meant as a criticism.
WACAH!
--
On Thu, Aug 11, 2016 at 8:31 AM, Gregory Ewing
wrote:
> Lawrence D’Oliveiro wrote:
>
>>> It will let you create non-leaky wrappers ...
>>
>>
>> Why would I want to do that?
>
>
> You mentioned that ctypes wrappers are leaky, which I
> assumed was meant as a criticism. But if you *like*
> your wrap
Lawrence D’Oliveiro wrote:
It will let you create non-leaky wrappers ...
Why would I want to do that?
You mentioned that ctypes wrappers are leaky, which I
assumed was meant as a criticism. But if you *like*
your wrappers to be leaky, by all means go for it. :-)
--
Greg
--
https://mail.pyth
On Wednesday, August 10, 2016 at 10:13:53 PM UTC+12, eryk sun wrote:
> ctypes classes have from_buffer and from_buffer_copy methods that use
> the buffer protocol. For example, for a read-only buffer you can use
> from_buffer_copy:
>
> >>> b = bytes(b'1234')
> >>> a = (ctypes.c_char * 3).
On Wed, Aug 10, 2016 at 1:45 AM, Lawrence D’Oliveiro
wrote:
>
> Ah, I wish... I had a look at the documentation for the buffer interface and
> memory views,
> and found no way to make use of them from pure Python. Basically, the
> paragraph I quoted
> above is wrong in just about every important
On Wednesday, August 10, 2016 at 6:35:57 PM UTC+12, Gregory Ewing wrote:
> It's talking about accessing the internals of an object from C or C++ code,
> *not* from Python.
It’s saying that’s “the only way to effectively make use of this information”,
which it is not.
> If you're using ctypes an
Lawrence D’Oliveiro wrote:
When using array objects from code written in C or C++ (the only way to
effectively make use of this information), it makes more sense to use the
buffer interface supported by array objects.
Ah, I wish... I had a look at the documentation for the buffer interface and
On Wed, 10 Aug 2016 11:45 am, Lawrence D’Oliveiro wrote:
> GvR has said “we’re all consenting adults here”. He was referring to the
> “public/private/protected” access-control business that most
> object-oriented languages require you to go through. But there is another
> area where I think this p
GvR has said “we’re all consenting adults here”. He was referring to the
“public/private/protected” access-control business that most object-oriented
languages require you to go through. But there is another area where I think
this principle applies to Python, at least in part: low-level access
13 matches
Mail list logo
