Найти - Пользователи
Полная версия: Python PEP (для С++ программистов)
Начало » Python для экспертов » Python PEP (для С++ программистов)
1
Trump
Не знаю как создать PEP (Python Enhancement Proposals, Предложение по Улучшению Питона).
У меня есть предложение, которое будет интересно для программистов на 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();
(Но вторая строка мне нравится больше 8-])
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++ программистам, но повлияет на скорость их модулей. Нужно ли это?
Cleric
Для С++ нет стандартизированного ABI (Application Binary Interface), так что С99 наше все:) Если вам не хватает высокоуровновасти при написании модулей расширений используйте pyrex.
Андрей Светлов
Python C API - низкоуровневый стандарт. И именно по причине низкоуровнвости это С API, а не C++.
И эта ситуация никогда не изменится.
Другое дело - ООП. Самому очень нравится. Но в том как раз и вся фишка, что API менять не нужно. Достаточно создать хорошую С++ надстройку (как это принято делать в подобных случаях).
Спасибо Дейву Абрамсу - она уже есть. boost.python

Хочется изобрести что-то еще? Свою уникальную модель велосипеда?
Trump
Cleric
Для С++ нет стандартизированного ABI (Application Binary Interface), так что С99 наше все:)
Но ведь я не добавляю никакие поля в структуры PyObject, PyListObject, PyFileObject, др. Я предлагаю лишь добавить методы. В результате получится, что sizeof(…) не изменится.
Trump
Андрей Светлов
Python C API - низкоуровневый стандарт. И именно по причине низкоуровнвости это С API, а не C++.
И эта ситуация никогда не изменится.
Другое дело - ООП. Самому очень нравится. Но в том как раз и вся фишка, что API менять не нужно. Достаточно создать хорошую С++ надстройку (как это принято делать в подобных случаях).
Спасибо Дейву Абрамсу - она уже есть. boost.python
boost.python, pyrex - это все объекто-ориентированные надстройки. А любый надстройки замедляют работу. То что я предложил - это лишь украшение синтаксиса, которое не влияет (почти) на скорость.
Андрей Светлов
Хочется изобрести что-то еще? Свою уникальную модель велосипеда?
Я погарячился, сказав об ООП. Мне больше хочется просто красивого синтаксиса object->method(argments…).
Я бы и сам мог сделать это. Ведь достаточно изменить заголовочные файлы. Все остальное останется нетронутым. Но самому - это долго. А к тому же если Гвидо ван Россум с друзьями и дальше будет изменять API, то мне одному будет сложнее за этим уследить.
Александр Кошелев
Trump
Но ведь я не добавляю никакие поля в структуры PyObject, PyListObject, PyFileObject, др. Я предлагаю лишь добавить методы. В результате получится, что sizeof(…) не изменится.
дело не в размере, а в компиляторе. в С нет методов у структур, а значит чтобы реализовать твою идею понадобится С++ компилятор. тут то и скажется отсутсвие ABI
Trump
Мне больше хочется просто красивого синтаксиса object->method(argments…).
мягко-говоря повод не велик:)
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB