У меня есть предложение, которое будет интересно для программистов на C++.
Идея состоит в том, чтобы добавить в API Питона немножко ООП.
Сейчас при написание модулей к Питону прихожится использовать функции вида PyList_Size(list), PyTuple_GetItem(tuple, index), др. Это связано с тем, что Питон полностью написан на C.
C++ позволяет добавлять к структурам (struct) методы наподобии классов. Эти методы будут поголовно inline, и будут состоят в большинстве своем из одной строки. Например:
в файле listobject.h (Python 2.5.1) есть объявление объекта “список”.
typedef struct {
PyObject_VAR_HEAD
PyObject **ob_item;
Py_ssize_t allocated;
} PyListObject;typedef struct {
PyObject_VAR_HEAD
PyObject **ob_item;
Py_ssize_t allocated;
#ifdef __cplusplus
static inline PyObject * New (Py_ssize_t size) { return PyList_New(size); }
inline Py_ssize_t Size () { return PyList_Size(this); }
inline PyObject * GetItem (Py_ssize_t index) { return PyList_GetItem(this, index); }
inline PyObject * AsTuple () { return PyList_AsTuple(this); }
/*etc*/
#endif
} PyListObject;1. Директива #ifdef __cplusplus гарантирует, что методы не будут обрабатываться C-компилятором. А только C++.
2. Добавленные методы никак не повлияют на существующий код Питоновских модулей. Все существующие модули будут компилироваться как и раньше.
3. Можно использовать как привычный API, так и объекто-ориентированный. То есть слудеющие две строки эквивалентны (и могут встречатся в одном и том же файле):
count = PyList_Size(list);
count = list->Size();
4. Скорость никак не изменится (из-за использования директивы inline). Точнее умный компилятор не сделает более медленный код.
5. Достаточно изменить заголовочные файлы (*.h) в папке include.
6. Сохраняется двоичная совместимость, т.е. размер объектов не изменятся ни на байт, и пользоваться указателями на “новые” объекты совершенно безопастно.
Отрицательные стороны:
1. Макросы придется превратить в inline методы.
2. В текущих исходниках сначала объявляется тип (PyObject, PyDictObject, PyFrameObject, др.), а только потом API для работы с ним. Придется поменять эти блоки местами, так как при объявлении типов методы уже используют API.
В связи с вышеизложенным у меня три вопроса:
1. Имеет ли смысл возится с улучшением Python API? И какие у кого идеи по этому поводу?
2. Как добавить это предложение для обсуждения в http://www.python.org/dev/peps/ ?
3. Есть идея сделать Python API полность объекто ориенториванным: классы с наследованием, конструкторы, деструкторы, автоматическое привидение типов, виртуальные функции (по мотивам умных указателей из книги “C++ for real programmers”). Это упростит жизнь C++ программистам, но повлияет на скорость их модулей. Нужно ли это?