Огромное спасибо. Нашел еще интересные пдф у Вас на сайте.

Всегда пожалуйста. Те интересные pdf пока в стадии доработки, тут буду их постить по мере окончательной готовности. А так их можно рассматривать как бонус для самых догадливых;-)))

Они и в стадии доработки хороши.

хорошая работа!

Хорошая пдфка, спасибо.

>Нашел еще интересные пдф у Вас на сайте.

А я сам сайт найти не могу, дай ссыль, а?

http://a-iv.ru/pyart/

Ммать моя. Я ж как раз питон изучать начал. ТС, спасибище тебе огромное! Пдфки качаю, ссыль схороню.

Я для изучения лучше книги чем Гвидо Ван Россума и Ко не видел, хоть она и для старой версии питона. С остальными ссылками - еще раз - ОСТОРОЖНЕЙ. Приведенная в них информация может не до конца соответствовать действительности, автор не несет отвественности за гибель ваших хомячков и пр.;-)))))

>С остальными ссылками - еще раз - ОСТОРОЖНЕЙ. Приведенная в них информация может не до конца соответствовать действительности, автор не несет отвественности за гибель ваших хомячков и пр.;-)))))

Ну я так, на почитать =)

Весь python в стадии доработки. Все уже свыклись что стандарта по факту нет. Адекватные люди не используют этот эксперимент для реальной работы, только экстремалы которым наплевать на потребителя. Лет через 10 пожалуйста.

> Весь python в стадии доработки. Все уже свыклись что стандарта по факту нет. Адекватные люди не используют этот эксперимент для реальной работы

Пожалуйста, продолжай информировать нас о технологиях, которые ты не используешь. Это очень, очень важно для нас всех.

> Я ж как раз питон изучать начал

Тогда сначала изучи ctypes - официальный FFI Питона. Потом - какой-нибудь современный генератор привязок.

>приложений на Python на порядок выше чем на C++, а их >производительность на три порядка ниже

Ну это вы батенька с порядками перегнули палку; в разы - да.

Описано интересно, хотя я предпочитаю либо ctypes, либо pyrex/cython. Насколько я знаю, через SWIG лучше всего можно привязать С++, но такие страшные вещи я стараюсь не привязывать))

Читал и плакал. Если у Вас уже есть код на C++, зачем конвертировать его в Питон? Чтобы оно тормозило? Я еще понимаю людей, которым C++ кажется трудным, и они пишут на питоне. Для них даже есть ниша, вероятно. Не в production, но где-то в утилитах, от которых не зависят ключевые моменты. Но вот если оно уже есть на C++ - зачем портить?

Читал и плакал.

Прочитай еще раз, внимательно только.

> Если у Вас уже есть код на C++, зачем конвертировать его в Питон?

Похоже, ты не понял того, что написано.

Прочитал. Я не могу столько плакать.

Не позорься.

>>приложений на Python на порядок выше чем на C++, а их производительность на три порядка ниже

Ну это вы батенька с порядками перегнули палку; в разы - да.

Цифирь по скорости разработки приведена навскидку из скромного личного пыта и сильно зависит от решаемой задачи, поэтому утверждение такое... весьма усредненное. По производительности - увы, медицинский факт.

> Весь python в стадии доработки. Все уже свыклись что стандарта по факту нет.

Начинается газификация луж.

> Пожалуйста, продолжайте информировать нас о технологиях, которые вы не используете. Это очень, очень важно для нас всех.

Оба, и здесь «технология»! Как ни увижу новый язычёк, так «технология»! Я не против новых языков, когда у них есть причина возникнования. И каждый язык сначала маргинален, и не устойчив в стандарте. Но никто ранше не додумывался совать сырое поделие во все края. 10 лет это минимум для языка.

А насчёт «не использую», извините, приходится использовать и мучиться с совместимостями. Ибо всякие бакланы на нём то мой portage напишут, то plugin.

Комплекс утёнка?

добавил в закладки

> А насчёт «не использую», извините, приходится использовать и мучиться с совместимостями. Ибо всякие бакланы на нём то мой portage напишут, то plugin.

Мы скорбим о твоей судьбе. Но, наверное, ты мазохист - использовать написанную бакланом генту, использовать portage вместо paludis (который накошерном Си++). Или тебе просто нравится ныть.

> Мы скорбим о вашей судьбе. Но, наверное, вы мазохист - использовать написанную бакланом генту, использовать portage вместо paludis (который накошерном Си++). Или вам просто нравится ныть.

Я-то пользуюсь paludis, но вынужден писать USE+=python-bindings, ибо 95% непреклонно диктуют свою волю по науськиванию быдловатыми хамамми вроде вас.

Более того, судя по emerge, на python даже по графу зависимстей, у людей явно лучше меня знающих этот язык, не получется ходить без костылей постоянно обратный поиск глючит. Это про гибкость и удобство python. Кто хочет может удостовериться. Сравните emerge -pvuDN и cave resolve -x --purge '*/*' по гибкости. Слева python справа убогий C++.

> 95% непреклонно диктуют свою волю по науськиванию быдловатыми хамамми вроде вас.

Голос меньшинств ITT

Кто хочет может удостовериться. Сравните emerge -pvuDN и cave resolve -x --purge '*/*' по гибкости. Слева python справа убогий C++.

Ну да, за все ошибки в программах на Питоне отвечает язык Питон и лично Гвидо ван Россум.

> Ну да, за все ошибки в программах на Питоне отвечает язык Питон и лично Гвидо ван Россум.

Я выше писал, что ничего против python-а не имею, но ишь после того как он пройдёт фазу которю проходят все языки после своего основания. Сейчас он только разрдражает.

Я напомню что сейчас его позиционируют как наше всё. Школиё нашло новый ответ на все вопросы. Им опять забыли рассказать про отличие порога вхождения от возможностей и гибкости в процессе использования, но орут они, как и полагается школию, громче всех. Демократия, естественно за самых громких. Что голубые в европе, что школиё в IT.

> Я выше писал, что ничего против python-а не имею

Ты выше поставил ошибки emerge в вину именно Питону.

но ишь после того как он пройдёт фазу которю проходят все языки после своего основания.

Бред.

Я напомню что сейчас его позиционируют как наше всё.

Бред.

> > Я напомню что сейчас его позиционируют как наше всё.

Бред.

Вы ещё и психиатр плохой. Это не бред, а комплекс. Может быть идиосинкразия?

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

> Но никто ранше не додумывался совать сырое поделие во все края. 10 лет это минимум для языка.

И никто, конечно же, не в курсе, что в этом году питону будет уже 20... :)

А по теме - большое спасибо, очень полезный документ:)

ну так о чем и говорят, что за 20 лет язык так и не стал стабильным и не имеет свои спеки. гвидо 20 лет играется в свою поделку и все наиграться не может. Вот теперь и школота подтягивает. Вроде бы взрослые, а играться еще хочется

Огромное спасибо. Я не фанат Python, но благодаря его сверхвысокому уровню и наличию «батареек», это очень удобный язык. А привязки к C++ - это очень нужное дело. Ведь некоторые вещи быстрей и удобней получаются на C++ из-за наличия готовых библиотек, привязок и т.д. Да и скорость у C++ на высоте. Так-что материал очень нужный. Да, я тоже все PDF-ки сгрузил, добавлю в библиотеку, в базу Calibre.

Ну почему же, вторая ветка достаточно стабильна. Документации на оф.сайте - море. С примерами и поэтессами.

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

Рад быть полезным;-)

насчет других pdf-ок, еще раз - они находятся в стадии разработки. Вы конечно можете их читать, но не советую их грузить в какие то базы непосредственно, т.к. они будут обновлятся.

Убрать их что ли от греха вообще...

ага:
http://www.python.org/dev/peps/pep-0384/
Defining a Stable ABI
...
On Linux, changes to the ABI are often not much of a problem: the system will provide a default Python installation, and many extension modules are already provided pre-compiled for that version. If additional modules are needed, or additional Python versions, users can typically compile them themselves on the system, resulting in modules that use the right ABI.
...

я аж прослезился
Python Language Moratorium
http://www.python.org/dev/peps/pep-3003/

This PEP proposes a temporary moratorium (suspension) of all changes to the Python language syntax, semantics, and built-ins for a period of at least two years from the release of Python 3.1. In particular, the moratorium would include Python 3.2 (to be released 18-24 months after 3.1) but allow Python 3.3 (assuming it is not released prematurely) to once again include language changes.

Rationale

This idea was proposed by Guido van Rossum on the python-ideas [1] (sic!!) mailing list. The premise of his email was to slow the alteration of the Python core syntax, builtins and semantics to allow non-CPython implementations to catch up to the current state of Python, both 2.x and 3.x.


т.е.,по прошествии 20 лет, не ломать что-то у них как «идея» проходит

занятно ...

Может вы про red-hat анаконду вспомнили?

А мне третья ветка категорически не нравится, главным образом из за потери обратной совместивмости - у меня боольшие сомнения в том, что их скрипт по автоконвертации правильно сконвертит все, что мной за 10 лет понаписано, причем я местами здорово извращался...

Да, кстати, пытался я эту штуку пользовать - как-то она не очень хорошо конвертит. А с нуля всё переписывать как-то ломает...

Так вы будете их обновлять, а я в свою библиотеку добавлять. Она же для личного пользования, да и при добавлении книги Calibre удаляет старый дубликат. Так-что у меня будет свежая версия ваших PDF. Не стоит их убирать. Пусть люди читают, учатся, пробуют сами творить. Может, ещё и дельные вопросы по теме, или мысли, может какие-то решения у кого-то появятся. Так это же всем на пользу будет. А база Calibre- всего лишь способ занесения книг, статей, заметок и журналов в каталог. Для удобного поиска по названию, автору описанию и т.д.

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

Кстати, если у вас много полезных материалов-тоже попробуйте установить Calibre. Кстати, эта программа написана на C++ и Python. И если у вас Ubuntu и последние KDE и PyQt4-она не запускается из-за траблы с SIP. Calibre в Ubuntu 10.10 написаны под SIP более старой версии, чем у последних PyQt4. И из-за этого сломалась работа progress bar-виджета. В общем, ставить прийдётся дистро-независимым способом, который разворачивает в /opt прогу с её зависимостями с одного тарбола.

А это чудо c bibtex-ом как то взаимодействует?

А как же буст::питон?

Странно, что вроде как еще никто не упомянул. Все не читал, из того, что читал буду первым. boost::python очень сильная вещь и при умелом использовании выводит приплюснутую ракету в питонный космос за несколько строк ;) В нашем проекте много занимался сабжем на бустпитоне. Посмотрел бегло ваш документ, на мой вкус слишком «низкоуровнево» выходит. Бустпитон позволяет избавиться от возни со счетчиками ссылок (в большинстве стандартных случаев), предусмотрены инструменты для обработки всяких передаваемых и возвращаемых массивов, указателей и ссылок, примитивные питоновские типы сразу доступны в C++, много чего еще. Ну и главное, нет нужды в отдельных файлах с метаинформацией (она записывается прямо в исходниках) и отдельной тулзы для их обработки, все делает сишный компилятор. Минусы тоже есть. Все-таки бустпитон — это та еще шаблонная магия. Нормально документированы только стандартные вещи + содержатся «намеки», куда копать, если нужно сделать что-то необычное. Причем оказывается, что в бустпитоне средства для этого заложены, но сразу этого не видно ) PySide отказались от него _только_ из-за того, что он у них генерировал большие по объему бинарники.

> Адекватные люди не используют этот эксперимент для реальной работы, только экстремалы которым наплевать на потребителя.

Это вы лихо про гугль сказали...

Я очень бегло смотрел на boost::python и остались смешанные чуйства. С одной стороны да, вcе красиво и никаких куч мусора типа _wrap.cxx. С другой - у меня не появилось впечателние о запуске в неск строк, наск я понял каждый метод придется цеплять ручками (да и как иначе можно сделать в рамках C++ без отдельного анализа исходников???). А я ленив страшно, да и классов/методов много...

Но я не специалист по бусту. Я написал о чем знаю, оно работает и вполне меня удовлетворяет - с предложенной идеологией Makefile импорт действительно требует буквально несколько строчек в общей сложности. Шаблоны и прочие изыски цепляются... Это мне надо будет сначла познать буст, потом переписать под него неск немаленьких проектов которые и так вполне функциклируют - для этого будут нужны ооочень веские основания;-)))

Да, для каждого метода/функции надо написать строчку экспорта, примерно так:

namespace bp = boost::python

class x {
public:
  void make_me_happy(int how_many) {
  //...
  }
  //...
};

bp::class_< x >("x_py")
  .def("make_me_happy", &x::make_me_happy)
  .def("yet_another_method", &x::yet_another_method)
  //...
  ;

Все остальное автоматом делается. Поглядел ваш труд, выходит SWIG сам вытягивает все это из сорцов. И как он справляется, нормально? Если кучерявый код или куча шаблонов — не тупит?

Вообще, чтобы юзать бустпитон совсем не обязательно знать «весь буст». Его вполне можно брать по необходимым тебе частям и не иметь понятия об остальных (ну почти). Я тоже совсем не могу похвастаться, что смотрел или пользовался хотя бы четвертью того, что там есть.

А по теме — ваша статья очень понравилась, весьма интересно. Плюсую )