A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2002-January/019604.html below:

[Python-Dev] Extending types in C

[Python-Dev] Extending types in C - help needed [Python-Dev] Extending types in C - help neededThomas Heller thomas.heller@ion-tof.com
Fri, 18 Jan 2002 22:21:59 +0100
> Also notice that this *does* make use of new-style classes: In 2.1,
> types did not have a tp_dict slot. Of course, the PyType_Ready call
> should go immediately before the place where tp_dict is accessed, and
> a check should be added whether tp_flags contains
> Py_TPFLAGS_HAVE_CLASS.
Wouldn't it suffice to check for tp_dict != NULL (after the call
to PyType_Ready of course)?

Hm. What does Py_TPFLAGS_HAVE_CLASS mean exactly?
Or, better, since TPFLAGS_DEFAULT contains TPFLAGS_HAVE_CLASS,
what does it mean when Py_TPFLAGS_HAVE_CLASS is NOT in tp_flags?
Does it mean that this is a 'new style' type object?

Thomas




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