Уведомления

Группа в Telegram: @pythonsu

#1 Окт. 21, 2007 01:13:40

Trump
От:
Зарегистрирован: 2007-10-21
Сообщения: 3
Репутация: +  0  -
Профиль   Отправить e-mail  

Python PEP (для С++ программистов)

Не знаю как создать 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++ программистам, но повлияет на скорость их модулей. Нужно ли это?



Офлайн

#2 Окт. 21, 2007 05:38:47

Cleric
От:
Зарегистрирован: 2007-06-26
Сообщения: 87
Репутация: +  0  -
Профиль   Отправить e-mail  

Python PEP (для С++ программистов)

Для С++ нет стандартизированного ABI (Application Binary Interface), так что С99 наше все:) Если вам не хватает высокоуровновасти при написании модулей расширений используйте pyrex.



Офлайн

#3 Окт. 21, 2007 06:58:14

Андрей Светлов
От:
Зарегистрирован: 2007-05-15
Сообщения: 3137
Репутация: +  14  -
Профиль   Адрес электронной почты  

Python PEP (для С++ программистов)

Python C API - низкоуровневый стандарт. И именно по причине низкоуровнвости это С API, а не C++.
И эта ситуация никогда не изменится.
Другое дело - ООП. Самому очень нравится. Но в том как раз и вся фишка, что API менять не нужно. Достаточно создать хорошую С++ надстройку (как это принято делать в подобных случаях).
Спасибо Дейву Абрамсу - она уже есть. boost.python

Хочется изобрести что-то еще? Свою уникальную модель велосипеда?



Офлайн

#4 Окт. 22, 2007 21:40:07

Trump
От:
Зарегистрирован: 2007-10-21
Сообщения: 3
Репутация: +  0  -
Профиль   Отправить e-mail  

Python PEP (для С++ программистов)

Cleric
Для С++ нет стандартизированного ABI (Application Binary Interface), так что С99 наше все:)
Но ведь я не добавляю никакие поля в структуры PyObject, PyListObject, PyFileObject, др. Я предлагаю лишь добавить методы. В результате получится, что sizeof(…) не изменится.



Офлайн

#5 Окт. 22, 2007 21:46:03

Trump
От:
Зарегистрирован: 2007-10-21
Сообщения: 3
Репутация: +  0  -
Профиль   Отправить e-mail  

Python PEP (для С++ программистов)

Андрей Светлов
Python C API - низкоуровневый стандарт. И именно по причине низкоуровнвости это С API, а не C++.
И эта ситуация никогда не изменится.
Другое дело - ООП. Самому очень нравится. Но в том как раз и вся фишка, что API менять не нужно. Достаточно создать хорошую С++ надстройку (как это принято делать в подобных случаях).
Спасибо Дейву Абрамсу - она уже есть. boost.python
boost.python, pyrex - это все объекто-ориентированные надстройки. А любый надстройки замедляют работу. То что я предложил - это лишь украшение синтаксиса, которое не влияет (почти) на скорость.
Андрей Светлов
Хочется изобрести что-то еще? Свою уникальную модель велосипеда?
Я погарячился, сказав об ООП. Мне больше хочется просто красивого синтаксиса object->method(argments…).
Я бы и сам мог сделать это. Ведь достаточно изменить заголовочные файлы. Все остальное останется нетронутым. Но самому - это долго. А к тому же если Гвидо ван Россум с друзьями и дальше будет изменять API, то мне одному будет сложнее за этим уследить.



Офлайн

#6 Окт. 22, 2007 22:04:54

Александр Кошелев
От: Москва
Зарегистрирован: 2007-02-03
Сообщения: 1724
Репутация: +  2  -
Профиль   Отправить e-mail  

Python PEP (для С++ программистов)

Trump
Но ведь я не добавляю никакие поля в структуры PyObject, PyListObject, PyFileObject, др. Я предлагаю лишь добавить методы. В результате получится, что sizeof(…) не изменится.
дело не в размере, а в компиляторе. в С нет методов у структур, а значит чтобы реализовать твою идею понадобится С++ компилятор. тут то и скажется отсутсвие ABI
Trump
Мне больше хочется просто красивого синтаксиса object->method(argments…).
мягко-говоря повод не велик:)



Офлайн

Board footer

Модераторировать

Powered by DjangoBB

Lo-Fi Version