[issue17950] Dynamic classes contain non-breakable reference cycles

Guido van Rossum added the comment: Good call. I think it's perfectly fine for you to do this in your custom 2.7 branch. It feels too fragile to adopt the same approach for Python 3.4 though. -- status: open -> closed ___ Python tracker

[issue17950] Dynamic classes contain non-breakable reference cycles

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, i

[issue17950] Dynamic classes contain non-breakable reference cycles

Guido van Rossum added the comment: Kristjan, it seems you're in over your head. :-) The mro() function is documented here: http://docs.python.org/3/library/stdtypes.html?highlight=mro#class.mro It exists to be called instead of using __mro__ directly; a metaclass can then override what it retu

[issue17950] Dynamic classes contain non-breakable reference cycles

Armin Rigo added the comment: Well, adding weak references left and right to break cycles is going to subtly change or break people's code and hasn't been done so far, but that's only my opinion. Anyway, I want to correct what you say about tp_subclasses: yes, tp_subclasses is a list of weakr

[issue17950] Dynamic classes contain non-breakable reference cycles

Kristján Valur Jónsson added the comment: Thanks Guido. The current patch provides the property you ask for. I will see if I can make the "fiddling" of the internal tuple less magical. I have one other question for you: The standard "mro" puts the class in the 0th position. But apparently, t

[issue17950] Dynamic classes contain non-breakable reference cycles

Guido van Rossum added the comment: I think turning the __mro__ tuple into a getter is fine. As long as this works I'm okay: class C: ... mro = C.__mro__ del C assert mro[0].__name__ == 'C' (The last assert stands in for asserting that the class object must stay alive as long as the tuple re

[issue17950] Dynamic classes contain non-breakable reference cycles

Changes by Daniel Urban : -- nosy: +daniel.urban ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue17950] Dynamic classes contain non-breakable reference cycles

Changes by Nick Coghlan : -- nosy: +ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue17950] Dynamic classes contain non-breakable reference cycles

Changes by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue17950] Dynamic classes contain non-breakable reference cycles

Changes by Martin Morrison : -- nosy: +isoschiz, pconnell ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue17950] Dynamic classes contain non-breakable reference cycles

Kristján Valur Jónsson added the comment: Hello Antoine. 1) Yes, I am not completely happy with the approach myself, but I'd like to get the ball rolling. One particular nuance is that there appears to be a way to provide a custom MRO, one which does not enforce the rule that the self type co

[issue17950] Dynamic classes contain non-breakable reference cycles

Antoine Pitrou added the comment: > 1) the mro tuple in the type object is "nerfed" to contain a > Py_None reference in its first place I like the idea, but I find the implementation (the new macros) quite convoluted. I think special-casing the first tuple element where necessary would be clea

[issue17950] Dynamic classes contain non-breakable reference cycles

Kristján Valur Jónsson added the comment: Adding file demonstraing the problem. -- Added file: http://bugs.python.org/file30208/classleak.py ___ Python tracker ___ __

[issue17950] Dynamic classes contain non-breakable reference cycles

New submission from Kristján Valur Jónsson: Classes contain two kinds of cycles back to themselves: 1) in their __mro_ list, the class itself is typically the first member. 2) in the descriptors for various fields such as __dict__. The problem here is that there is no way to break the cycle. A