On Sat, 19 Jan 2019 13:28:06 +1300
Greg Ewing wrote:
> Tim Peters wrote:
>
> > The dict itself keeps the objects alive.
>
> Yes, but the idea of a cache is that you're free to flush
> things out of it to make room for something else without
> breaking anything.
>
> It sounds like MRAB is
On 1/18/19, Steven D'Aprano wrote:
> On Thu, Jan 17, 2019 at 07:50:51AM -0600, eryk sun wrote:
>>
>> It's kind of dangerous to pass an object to C without an increment of
>> its reference count.
>
> "Kind of dangerous?" How dangerous?
I take that back. Dangerous is too strong of a word. It can
On 2019-01-19 00:28, Greg Ewing wrote:
Tim Peters wrote:
The dict itself keeps the objects alive.
Yes, but the idea of a cache is that you're free to flush
things out of it to make room for something else without
breaking anything.
It sounds like MRAB is using ids as weak references,
Steven D'Aprano wrote:
The sample code I've been shown is this:
pointer_to_obj = id(obj)
from_deref = ctypes.cast(pointer_to_obj, ctypes.py_object).value
from_deref is obj # True
There's no need to use id() or casting to create a ctypes.py_object
instance, you can just call it:
Tim Peters wrote:
The dict itself keeps the objects alive.
Yes, but the idea of a cache is that you're free to flush
things out of it to make room for something else without
breaking anything.
It sounds like MRAB is using ids as weak references,
without the assurance actual weak references
On 2019-01-18 23:02, Greg Ewing wrote:
MRAB wrote:
If I want to cache some objects, I put them in a dict, using the id as
the key. If I wanted to locate an object in a cache and didn't have
id(), I'd have to do a linear search for it.
That sounds dangerous. An id() is only valid as long as
[MRAB]
>> If I want to cache some objects, I put them in a dict, using the id as
>> the key. If I wanted to locate an object in a cache and didn't have
>> id(), I'd have to do a linear search for it.
[Greg Ewing ]
> That sounds dangerous. An id() is only valid as long as the object
> it came
MRAB wrote:
If I want to cache some objects, I put them in a dict, using the id as
the key. If I wanted to locate an object in a cache and didn't have
id(), I'd have to do a linear search for it.
That sounds dangerous. An id() is only valid as long as the object
it came from still exists,
On Sat, Jan 19, 2019 at 9:58 AM Greg Ewing wrote:
>
> Chris Angelico wrote:
> > I would be strongly in favour of ctypes gaining a "get address of
> > object" function, which happens (in current CPythons) to return the
> > same value as id() does, but is specifically tied to ctypes.
>
> Isn't this
Chris Angelico wrote:
I would be strongly in favour of ctypes gaining a "get address of
object" function, which happens (in current CPythons) to return the
same value as id() does, but is specifically tied to ctypes.
Isn't this what the ctypes.py_object type is for?
Also, any code that does
Oh, bracket my brain glitch on small integers. Yes, they still give id()
of memory address, they just get reused, which is different. Nonetheless,
I never teach id(obj)
== ctypes.c_void_p.from_buffer(ctypes.py_object(b)).value ... and not only
because I only learned the latter spelling from eryk
On Fri, Jan 18, 2019, 5:55 AM Antoine Pitrou
> > id() returning the address of the object should be a guaranteed feature
>
> For me, the definitive answer is "yes, it's a CPython feature".
> That doesn't mean the CPython feature has to live forever. We may want
> to deprecate it at some point
On 18 Jan 2019, at 11:57, Antoine Pitrou wrote:
On Fri, 18 Jan 2019 03:00:54 +
MRAB wrote:
On 2019-01-18 00:48, Gregory P. Smith wrote:
I've heard that libraries using ctypes, cffi, or cython code of
various
sorts in the real world wild today does abuse the unfortunate side
effect of
On Thu, Jan 17, 2019 at 10:09:36PM -0800, Steve Dower wrote:
> For everyone who managed to reply *hours* after Eryk Sun posted the
> correct answer and still get it wrong, here it is again in full.
Sorry, I'm confused by your response here. As far as I can see, nobody
except Eryk Sun gave any
On Thu, 17 Jan 2019 22:18:13 -0800
Steve Dower wrote:
> I feel like I should clarify - not everyone who posted got it wrong, and
> I understand there's a side discussion among those who are also
> interested/participants in
>
On Fri, 18 Jan 2019 03:00:54 +
MRAB wrote:
> On 2019-01-18 00:48, Gregory P. Smith wrote:
> > I've heard that libraries using ctypes, cffi, or cython code of various
> > sorts in the real world wild today does abuse the unfortunate side
> > effect of CPython's implementation of id(). I
On Fri, 18 Jan 2019 00:18:17 -0800
Nathaniel Smith wrote:
> On Thu, Jan 17, 2019, 22:11 Steve Dower
> > For everyone who managed to reply *hours* after Eryk Sun posted the
> > correct answer and still get it wrong, here it is again in full.
> >
> > As a bonus, here's a link to the place where
On Fri, 18 Jan 2019 20:49:26 +1100
Steven D'Aprano wrote:
>
> Language-wise, I'm trying to get a definitive answer of whether or not
> id() returning the address of the object should be a guaranteed feature
> or not.
For me, the definitive answer is "yes, it's a CPython feature".
However,
Thanks for the detailed answer. A further question below.
On Thu, Jan 17, 2019 at 07:50:51AM -0600, eryk sun wrote:
> On 1/17/19, Steven D'Aprano wrote:
> >
> > I understand that the only way to pass the address of an object to
> > ctypes is to use that id. Is that intentional?
>
> It's kind
On Fri, Jan 18, 2019 at 1:51 AM Steven D'Aprano wrote:
> Across the entire Python ecosystem, no it isn't, as Jython and
> IronPython return consecutive integers. But should we consider it an
> intentional part of the CPython API?
It's always worked, there's substantial code in the wild that
On Thu, Jan 17, 2019 at 04:48:38PM -0800, Gregory P. Smith wrote:
> I've heard that libraries using ctypes, cffi, or cython code of various
> sorts in the real world wild today does abuse the unfortunate side effect
> of CPython's implementation of id(). I don't have specific instances of
> this
On Fri, 18 Jan 2019 at 09:52, Steven D'Aprano wrote:
> Code-wise, I'm not doing anything with ctypes.
>
> Language-wise, I'm trying to get a definitive answer of whether or not
> id() returning the address of the object should be a guaranteed feature
> or not.
>
> Across the entire Python
On Thu, Jan 17, 2019 at 11:37:13AM +0100, Antoine Pitrou wrote:
I said:
> > The id() function is documented as returning an abstract ID number. In
> > CPython, that happens to have been implemented as the address of the
> > object.
> >
> > I understand that the only way to pass the address of
On Thu, Jan 17, 2019, 22:11 Steve Dower For everyone who managed to reply *hours* after Eryk Sun posted the
> correct answer and still get it wrong, here it is again in full.
>
> As a bonus, here's a link to the place where this answer appears in the
> documentation:
>
I feel like I should clarify - not everyone who posted got it wrong, and
I understand there's a side discussion among those who are also
interested/participants in
https://discuss.python.org/t/demoting-the-is-operator-to-avoid-an-identity-crisis/86/
- but there was no of acknowledgement of Eryk
For everyone who managed to reply *hours* after Eryk Sun posted the
correct answer and still get it wrong, here it is again in full.
As a bonus, here's a link to the place where this answer appears in the
documentation:
https://docs.python.org/3/library/ctypes.html#ctypes.py_object
Cheers,
Steve
n Thu, Jan 17, 2019 at 4:51 PM Gregory P. Smith wrote:
>
> I've heard that libraries using ctypes, cffi, or cython code of various sorts
> in the real world wild today does abuse the unfortunate side effect of
> CPython's implementation of id(). I don't have specific instances of this in
>
On 2019-01-18 00:48, Gregory P. Smith wrote:
I've heard that libraries using ctypes, cffi, or cython code of various
sorts in the real world wild today does abuse the unfortunate side
effect of CPython's implementation of id(). I don't have specific
instances of this in mind but trust what
On Fri, Jan 18, 2019 at 11:50 AM Gregory P. Smith wrote:
>
> I've heard that libraries using ctypes, cffi, or cython code of various sorts
> in the real world wild today does abuse the unfortunate side effect of
> CPython's implementation of id(). I don't have specific instances of this in
>
I've heard that libraries using ctypes, cffi, or cython code of various
sorts in the real world wild today does abuse the unfortunate side effect
of CPython's implementation of id(). I don't have specific instances of
this in mind but trust what I've heard: that it is happening.
id() should never
On 1/17/19, Steven D'Aprano wrote:
>
> I understand that the only way to pass the address of an object to
> ctypes is to use that id. Is that intentional?
It's kind of dangerous to pass an object to C without an increment of
its reference count. The proper way is to use a simple pointer of type
On Thu, 17 Jan 2019 21:26:06 +1100
Steven D'Aprano wrote:
> Disclaimer: I'm not a ctypes expert, so I might have this completely
> wrong. If so, I apologise for the noise.
>
> The id() function is documented as returning an abstract ID number. In
> CPython, that happens to have been
Disclaimer: I'm not a ctypes expert, so I might have this completely
wrong. If so, I apologise for the noise.
The id() function is documented as returning an abstract ID number. In
CPython, that happens to have been implemented as the address of the
object.
I understand that the only way to
33 matches
Mail list logo