Я почти закончил переписывать оболочку C ++ Python (PyCXX).

Оригинал позволяет использовать классы расширения старого и нового стилей, но также позволяет создавать производные от классов нового стиля:

import test

// ok
a = test.new_style_class();

// also ok
class Derived( test.new_style_class() ):
    def __init__( self ):
        test_funcmapper.new_style_class.__init__( self )

    def derived_func( self ):
        print( 'derived_func' )
        super().func_noargs()

    def func_noargs( self ):
        print( 'derived func_noargs' )

d = Derived()

Код запутан и, кажется, содержит ошибки (Почему PyCXX обрабатывает классы нового стиля таким же образом?)

Мой вопрос:Каково обоснование / обоснование извилистого механизма PyCXX? Есть ли более чистая альтернатива?

Ниже я попытаюсь подробно рассказать, где я нахожусь с этим расследованием. Сначала я попытаюсь описать, что PyCXX делает в данный момент, затем я опишу то, что, я думаю, может быть улучшено.

Когда среда выполнения Python встречаетd = Derived(), оно делаетPyObject_Call( ob ) where ob is thePyTypeObjectforNewStyleClass. I will writeО.Б.asNewStyleClass_PyTypeObject`.

Этот PyTypeObject был построен в C ++ и зарегистрирован с использованиемPyType_Ready

PyObject_Call вызоветtype_call(PyTypeObject *type, PyObject *args, PyObject *kwds), возвращая инициализированный производный экземпляр, т.е.

PyObject* derived_instance = type_call(NewStyleClass_PyTypeObject, NULL, NULL)

Что-то вроде этого.

(Все это исходит из (http://eli.thegreenplace.net/2012/04/16/python-object-creation-sequence кстати, спасибо, Элай!)

type_call делает по существу:

type->tp_new(type, args, kwds);
type->tp_init(obj, args, kwds);

И наша оболочка C ++ вставила функции вtp_new а такжеtp_init слотыNewStyleClass_PyTypeObject что-то вроде этого:

typeobject.set_tp_new( extension_object_new );
typeobject.set_tp_init( extension_object_init );

:
    static PyObject* extension_object_new( PyTypeObject* subtype, 
                                              PyObject* args, PyObject* kwds )
    {
        PyObject* pyob = subtype->tp_alloc(subtype,0);

        Bridge* o = reinterpret_cast<Bridge *>( pyob );

        o->m_pycxx_object = nullptr;

        return pyob;
    }

    static int extension_object_init( PyObject* _self, 
                                            PyObject* args, PyObject* kwds )
    {
        Bridge* self{ reinterpret_cast<Bridge*>(_self) };

        // NOTE: observe this is where we invoke the constructor, 
        //       but indirectly (i.e. through final)
        self->m_pycxx_object = new FinalClass{ self, args, kwds };

        return 0;
    }

Обратите внимание, что нам нужно связать вместе экземпляр Python Derived и его соответствующий экземпляр класса C ++. (Почему? Объяснено ниже, см. «Х»). Для этого мы используем:

struct Bridge
{
    PyObject_HEAD // <-- a PyObject
    ExtObjBase* m_pycxx_object;
}

Теперь этот мост поднимает вопрос. Я очень подозрительно отношусь к этому дизайну.

Обратите внимание, как память была выделена для этого нового PyObject:

        PyObject* pyob = subtype->tp_alloc(subtype,0);

И затем мы приведем этот указатель кBridgeи используйте 4 или 8 (sizeof(void*)байт сразу послеPyObject указать на соответствующий экземпляр класса C ++ (это подключается вextension_object_init как видно выше).

Теперь, чтобы это работало, нам нужно:

а)subtype->tp_alloc(subtype,0) должен выделять дополнительныйsizeof(void*) байт б)PyObject не требует никакой памяти заsizeof(PyObject_HEAD), потому что если бы это было так, то это будет конфликтовать с указателем выше

На данный момент у меня есть один важный вопрос: можем ли мы гарантировать, чтоPyObject что среда исполнения Python создала для нашегоderived_instance не пересекается с бриджемExtObjBase* m_pycxx_object поле?

Я попытаюсь ответить на него: именно США определяют, сколько памяти будет выделено. Когда мы создаемNewStyleClass_PyTypeObject мы кормим, сколько памяти мы хотим, чтобы этоPyTypeObject выделить для нового экземпляра этого типа:

template< TEMPLATE_TYPENAME FinalClass >
class ExtObjBase : public FuncMapper<FinalClass> , public ExtObjBase_noTemplate
{
protected:
    static TypeObject& typeobject()
    {
        static TypeObject* t{ nullptr };
        if( ! t )
            t = new TypeObject{ sizeof(FinalClass), typeid(FinalClass).name() };
                   /*           ^^^^^^^^^^^^^^^^^ this is the bug BTW!
                        The C++ Derived class instance never gets deposited
                        In the memory allocated by the Python runtime
                        (controlled by this parameter)

                        This value should be sizeof(Bridge) -- as pointed out
                        in the answer to the question linked above

        return *t;
    }
:
}

class TypeObject
{
private:
    PyTypeObject* table;

    // these tables fit into the main table via pointers
    PySequenceMethods*       sequence_table;
    PyMappingMethods*        mapping_table;
    PyNumberMethods*         number_table;
    PyBufferProcs*           buffer_table;

public:
    PyTypeObject* type_object() const
    {
        return table;
    }

    // NOTE: if you define one sequence method you must define all of them except the assigns

    TypeObject( size_t size_bytes, const char* default_name )
        : table{ new PyTypeObject{} }  // {} sets to 0
        , sequence_table{}
        , mapping_table{}
        , number_table{}
        , buffer_table{}
    {
        PyObject* table_as_object = reinterpret_cast<PyObject* >( table );

        *table_as_object = PyObject{ _PyObject_EXTRA_INIT  1, NULL }; 
        // ^ py_object_initializer -- NULL because type must be init'd by user

        table_as_object->ob_type = _Type_Type();

        // QQQ table->ob_size = 0;
        table->tp_name              = const_cast<char *>( default_name );
        table->tp_basicsize         = size_bytes;
        table->tp_itemsize          = 0; // sizeof(void*); // so as to store extra pointer

        table->tp_dealloc           = ...

Вы можете увидеть это какtable->tp_basicsize

Но теперь мне кажется, что PyObject-ы генерируются изNewStyleClass_PyTypeObject никогда не потребует дополнительной выделенной памяти.

Что означает, что это целоеBridge Механизм не нужен.

И оригинальный метод PyCXX для использования PyObject в качестве базового классаNewStyleClassCXXClassи инициализировать эту базу так, чтобы PyObject среды выполнения Python дляd = Derived() на самом деле эта база, эта техника выглядит хорошо. Потому что это позволяет бесшовную типизацию.

Всякий раз, когда среда выполнения Python вызывает слот изNewStyleClass_PyTypeObject, он будет передавать указатель на PyObject d в качестве первого параметра, и мы можем просто ввести обратноNewStyleClassCXXClass, <- 'X' (ссылка выше)

Поэтому на самом деле мой вопрос: почему бы нам просто не сделать это?Есть ли что-то особенное в выводе изNewStyleClass что вызывает дополнительное выделение для PyObject?

Я понимаю, что не понимаю последовательность создания в случае производного класса. Пост Элая не охватывал это.

Я подозреваю, что это может быть связано с тем, что

    static PyObject* extension_object_new( PyTypeObject* subtype, ...

^ это имя переменной 'subtype'. Я не понимаю этого, и мне интересно, может ли это содержать ключ.

РЕДАКТИРОВАТЬ: я подумал об одном возможном объяснении того, почему PyCXX использует sizeof (FinalClass) для инициализации. Это может быть пережитком идеи, которую попробовали и отбросили. Т.е. если вызов Python tp_new выделяет достаточно места для FinalClass (в качестве базы которого используется PyObject), возможно, новый FinalClass может быть сгенерирован в этом точном месте с использованием 'размещения нового' или некоторого хитрого бизнеса reinterpret_cast. Я предполагаю, что это можно было попытаться найти, создать какую-то проблему, обойти, и реликвия осталась позади.