Андрей Светлов
Не только yield. Неприятно удивило, что в Cython отсутствуют class attributes. Было и еще по мелочам.

Всё равно остаётся из чего выбрать =)

Андрей Светлов
Про release и debug - ничего не понял.

Суть в том что релиз в такой комбинации можно собрать только из шела, или с помощью отдельного скрипта. ПрепроцесСор - это более менее удобное решение для поддержания совместимости.
P.S. Даже не релиз а вообще любой питоновский проект оптимизированный ситоном.

Окончательно запутался. Видимо, мы совсем по разному используем Python/Cython.

Андрей Светлов
Окончательно запутался. Видимо, мы совсем по разному используем Python/Cython.

Давай распутаем, объясняй как у тебя.

alexx11
Давай распутаем

Хорошо, я попробую первый шаг. Изложу вышесказанное, на пальцах.

Типичный проект, который надо оптимизировать
1. Кодинг букв на Python.
2. Выбор критических участков кода, подлежащих оптимизации.
3. Перевод этой части кода в Cython.
4. Сборка. Теперь мы имеем проект на двух языках, который надо собирать двумя различными сборщиками. Вообще говоря не сложно.
5. Запуск. Тестирование.
6. ??? Проделать пп1-5 N раз.
7. PROFIT

Одни хитрые люди подумали, что если меньше собирать то можно больше кодить, и решили сделать п.3 такой что б он был на 2 языках одновременно (т.е. совместить с п.1), а переключался препроцессором. В таком случае сборка понадобится всего лишь один раз, непосредственно перед п.7, все остальные разы это обычный проект на Python. А хитрые они потому что препроцессора в питоне нет, а gpp перекручен через одно место.
Да ещё, чуть не забыл ещё: п4 включает в себя ловлю блох на Cython, что при каждой сборке должно “доставлять” тру питонеру.

alexx11
2. Выбор критических участков кода, подлежащих оптимизации.
3. Перевод этой части кода в Cython.

Полезно иметь две версии - Python и Cython. Переключать их, например, так: если есть Cython оптимизация - используем ее.
Нет - возвращаемся к pure python implementation. Оставляем возможность принудительного использования pure python для тестирования.
Делается, например, через установку environment variable.

alexx11
4. Сборка. Теперь мы имеем проект на двух языках, который надо собирать двумя различными сборщиками. Вообще говоря не сложно.

Пишем setup.py в котором все есть. Для сборки нужно выполнить setup.py install или setup.py develop

alexx11
5. Запуск. Тестирование.

Как правило Cython модули великолепно подходят для юниттестов. Которые тоже запускаются одной командой.

Проверять Cython модули нужно всё равно в “рабочей” конфигурации, причем постоянно.
Это связано с тем, что при оптимизации довольно сильно изменяется реализация при неизменном public API.

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

Как-то так. При этом подходе не вижу необходимости в препроцессоре - все и так получается быстро и здорово.

Андрей Светлов Я понял, попробую подытожить в двух словах и привести сравнение.
В пользу препроцессора.
Синхронизация кода.
Разделение труда. (кодим, потом собираем.)

В пользу комплексной сборки.
Не нужен препроцессор.
Повышенная готовность, рабочей версии.

Андрей Светлов
При этом подходе не вижу необходимости в препроцессоре

Возможно, мне как новичку, который стоит в начале пути, перед выбором одного из вариантов, хочется велосипед понадёжней и побыстрей, и легче принимаются подобные решения. Поэтому я думаю таки да, ситону быть, и препроцессору тоже =)

Используя свой опыт программирования, выращенный из … (пропускаю) и приведший к си++ (как универсальному инструменту) , могу сказать, что питон самодостаточен (CPython - это от лукавого). Но питон без си - это то же самое, что полиэтиленовые пакетики без химической промышленности. Другими словами, надо быть готовым уметь при необходимости писать даже на ассемблере (а значит чухать ресурсы). Что я хочу сказать, нельзя понять интегральное уравнение, если не знаешь таблицу умножения.

alexx11, мой подход не является чем-то уникальным - так работают на очень многих проектах, начиная с CPython.

Isem
CPython - это от лукавого.

Это как?
Ежели имелся в виду Cython - то утверждение тоже не верное. Очень удобный способ писать C Extensions. Один из самых лучших, ИМХО. Для плюсов еще есть альтернативы, но в мире С Cython весьма неплох.

Андрей Светлов
Ежели имелся в виду Cython - то утверждение тоже не верное. Очень удобный способ писать C Extensions. Один из самых лучших, ИМХО. Для плюсов еще есть альтернативы, но в мире С Cython весьма неплох.

Cython, конечно же.
Только чем плох Python тогда?
Я не говорю, что Cython-ом не надо пользоваться. Считаем, что это просто библиотека (нестандартная) для питона. Он не базисный с точки зрения фундаментального подхода к программированию (об этом речь, как я понимаю).