id() collisions on bound methods [was: metaclass and customization with parameters]
exarkun at divmod.com
exarkun at divmod.com
Tue Oct 5 19:57:52 EDT 2004
More information about the Python-list mailing list
Tue Oct 5 19:57:52 EDT 2004
- Previous message (by thread): id() collisions on bound methods [was: metaclass and customization with parameters]
- Next message (by thread): id() collisions on bound methods [was: metaclass and customization with parameters]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, 5 Oct 2004 16:50:33 -0700, "Robert Brewer" <fumanchu at amor.org> wrote: > [snip] > >>> f = Foo() > >>> id(f.method0) > 18569136 > >>> id(f.method1) > 18536648 > >>> id(f.method2) > 18536648 > >>> id(f.method0) > 18536648 > > ...so the id() result is mutating somehow, even for the same object. > This is true for both old- and new-style classes, by the way, and also > holds for methods where you don't simply pass (I tried return 0, > return1, and return 2, for example function bodies) id() is only guaranteed unique *for the lifetime of the object*. As soon as the object ceases to exist, its id may appear as the id for any other object. In the above example, this makes a lot of sense if you understand a few things: 1) instanceObj.methodAttr results in a *new* bound method object every time it is evaluated. 2) The CPython id() implementation uses the value of the pointer to a PyObject. 3) Objects of the same size/type allocates and de-allocated in rapid succession often have a fairly high chance of being allocated the same memory in CPython. Jp
- Previous message (by thread): id() collisions on bound methods [was: metaclass and customization with parameters]
- Next message (by thread): id() collisions on bound methods [was: metaclass and customization with parameters]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list