[issue17950] Dynamic classes contain non-breakable reference cycles

[Kristján Valur Jónsson]

Kristján Valur Jónsson added the comment:

Armin:  Of course you are right.  This is what weak references are for, in a gc world, although their convenience to avoid cycles and enable reference counting to work always makes me forget.

I have another ongoing issue regarding tp_subclasses, btw, in issue #17936.

Guido: Yes, it is complicated.  The reason I am doing this is because I'm working to incorporate these changes in our stackless 2.7 branch.  I figured this might be useful to Python at large, hence this submission.  relying on gc is not an option when using python in a performance sensitive environment.  there are a few places in the core that cause cycles and I'm always keen to try to remove those.  Of course we can avoid the dynamic creation of classes, which is perhaps somewhat exotic.  But it is a simpler problem than the reference cylcle inherent in recursive closures.  I had a crack at that a week ago and ran in to a wall, so I thought I'd set myself an easier target :)

Thanks for clarifying mro().  What I was driving at was that without mro(), then type == type->tp_mro[0].  and knowing this, it is easy to put a None in tp_mro[0].  With a custom mro(), this restriction is no longer valid.  But my patch deals with this by verifying the assumption.  So, there is no big problem there.

I hear you worry a bit about performance for descriptors.  Performance is indeed a valid concern, but I"m not sure that an extra C indirection will show up on any readings, given that the next thing that happens is typically the creation of a bound method or the like, with all the stuff that entails.

I am not too worried about possibly returning NULL.  That's a technical detail that is fixable.
A much better question is whether this is worth doing at all because the practice I'm trying to optimize is probably a rare practice as you point out.  When do you truly need to create throwaway classes?  Most places that do are simply defining classes in a function scope as a means of name scoping, not realizing that each function invocation will create a unique metaclass instance and cost a non-trivial amount of cpu.

So, after this interesting sojourn into the bowels of typeobject.c, and these most enlightening discussions with you (Armin, Guido, Antoine) I don't think I'll pursue this any further.

Cheers!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17950>
_______________________________________