> The issue of > http://aspn.activestate.com/ASPN/Mail/Message/python-dev/1041123 is > back. (BTW, the ASPN archives of python-dev are much prettier-looking than the pipermail ones, and they are searchable. Maybe Barry or Jeremy could update the list info to also point to the ASPN archives?) > I had removed Py_TPFLAGS_HAVE_GC from my type, but as Thomas pointed out > in http://aspn.activestate.com/ASPN/Mail/Message/python-dev/1039576, > the flag is set again by PyType_Ready(). That would be fine if the > tp_is_gc field, which is initially zero in my metatype object, were > copied automatically from its base (PyTYpe_Type). As it stands, my > metatype is "forced" to inherit a claim that it handles GC, but the > machinery for determining whether a given instance of the metatype > is GC-able is /not/ inherited. Thus, my statically-allocated base > instance is treated as though it was allocated by the GC mechanism. Note that if a subtype provides its own tp_traverse and/or tp_clear, it does *not* inherit the HAVE_GC flag. (I'm not sure if this helps.) > This seems unneccessarily dangerous to me, and I propose that we > change the semantics of type inheritance to inherit tp_is_gc by > default. Agreed. I think this was purely an oversight. Looking at the end of inherit_slots(), I notice that tp_new isn't inherited either -- I think that needs to be added to the list of inherited slots too. > Further, I think this points out the need for clarification of the > subtyping mechanism. There should be one place where I can see which > flags and tp_xxx slots are inherited, what they mean, in addition to > the answers to other mysteries hidden in typeobject.c et al. I'm > willing to work something up, if I can get some guidance as to the > most appropriate form. It's not clear to me that there's an > appropriate place in the structure of the API docs (it's not even > clear to me that the API docs are the right place for this). The API docs *are* the right place. If you hate LaTeX, you can write the docs as plain text and send them to the appropriate channels -- they will magically be turned into LaTeX. (Maybe you can give reST a try? I'm sure that at some point we'll need an automatic translator to py-doc-latex, so we might as well get started on that now.) --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4