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
ACTIVITY SUMMARY (2019-01-11 - 2019-01-18)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open6932 ( +0)
closed 40595 (+58)
total 47527 (+58)
Open issues
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:
>
23 matches
Mail list logo
