I means remove the circular references without hurt the code, that is,
these two object will be destroyed at the same time. Even there
creation time is differ
2012/4/9, Stefan Behnel :
> 罗勇刚(Yonggang Luo) , 09.04.2012 04:28:
>> static PyObject *
>> Repository_get_index(Repository *self, void *clos
罗勇刚(Yonggang Luo) , 09.04.2012 04:28:
> static PyObject *
> Repository_get_index(Repository *self, void *closure)
> {
> int err;
> git_index *index;
> Index *py_index;
>
> assert(self->repo);
>
> if (self->index == NULL) {
> err = git_repository_index(&index, self->rep
Magnus Lyckå writes:
a = X()
del a
> Deleted <__main__.X instance at 0x00CCCF80>
a=X()
b=X()
a.b=b
b.a=a
del a
gc.collect()
> 0
del b
gc.collect()
> 4
If your method has a __del__ at all, the automatic cyclic collector is
disabled. It detects th
On 2011-01-07 03:24, moerchendiser2k3 wrote:
Everything works fine, the problem starts when I start to make a
circular reference in Python.
I didn't quite grok your example, but concerning CPython GC & circular
references...
>>> import gc
>>> class X:
... def __del__(self):
...
moerchendiser2k3, 10.01.2011 22:19:
On Jan 10, 7:18 pm, Stefan Behnel wrote:
moerchendiser2k3, 10.01.2011 18:55:
If you can tell us why it's so important that the object be destroyed
at that given time, even while a reference to it exists, maybe we can
give you better suggestions.
Thanks fo
On Jan 10, 7:18 pm, Stefan Behnel wrote:
> moerchendiser2k3, 10.01.2011 18:55:
>
> >> If you can tell us why it's so important that the object be destroyed
> >> at that given time, even while a reference to it exists, maybe we can
> >> give you better suggestions.
>
> > Thanks for your answer! In
moerchendiser2k3, 10.01.2011 18:55:
If you can tell us why it's so important that the object be destroyed
at that given time, even while a reference to it exists, maybe we can
give you better suggestions.
Thanks for your answer! In my case the types A and B (in my example
above)
are a dialog an
> If you can tell us why it's so important that the object be destroyed
> at that given time, even while a reference to it exists, maybe we can
> give you better suggestions.
Thanks for your answer! In my case the types A and B (in my example
above)
are a dialog and a dialog widget. At a special t
On Jan 10, 12:21 am, moerchendiser2k3 wrote:
> so there is no chance without using weakrefs?
> any ideas, tips, workarounds how I might handle this?
No, sorry: as long as a reference to an object exists, the object is
never deleted. There is no way to get around this.
Python in general isn't de
so there is no chance without using weakrefs?
any ideas, tips, workarounds how I might handle this?
bye, moerchendiser2k3
--
http://mail.python.org/mailman/listinfo/python-list
On Jan 7, 3:58 am, moerchendiser2k3 wrote:
> > Force what?
> > j refers to i, i refers to Foo, Foo refers to A. Therefore A should be
> > alive.
>
> Oh, sorry. Force the deletion of instance Foo(A) and Bar(B).
If you don't want j to keep i alive, you should look at weak
referencing. (Look at the
> Force what?
> j refers to i, i refers to Foo, Foo refers to A. Therefore A should be
> alive.
Oh, sorry. Force the deletion of instance Foo(A) and Bar(B).
--
http://mail.python.org/mailman/listinfo/python-list
> Force what?
>
> j refers to i, i refers to Foo, Foo refers to A. Therefore A should be
> alive.
Oh, sorry. Force the deletion of A.
--
http://mail.python.org/mailman/listinfo/python-list
On 07/01/2011 02:24, moerchendiser2k3 wrote:
Hi,
I have a small problem with circular references. I embedded Python
into my app and I have two types which are flagged with
Py_TPFLAGS_BASETYPE so I can inherit Python types from these types.
Lets call my C types A and B.
Here is the dependency:
Hi,
I have a small problem with circular references. I embedded Python
into my app and I have two types which are flagged with
Py_TPFLAGS_BASETYPE so I can inherit Python types from these types.
Lets call my C types A and B.
Here is the dependency:
class Foo(A):
e=Bar()
class Bar(B):
d
15 matches
Mail list logo
