Python *

Введение

Добрый день, уважаемые читатели.
После написания предыдущего поста про анализ временных рядов на Python, я решил исправить замечания, которые были указаны в комментариях, но при их исправлении я столкнулся с рядом проблем, например при построении сезонной модели ARIMA, т.к. подобной функции а пакете statsmodels я не нашел. В итоге я решил использовать для этого функции из R, а поиски привели меня к библиотеке rpy2 которая позволяетиспользовать функции из библиотек упомянутого языка.
У многих может возникнуть вопрос «зачем это нужно?», ведь проще просто взять R и выполнить всю работу в нем. Я полность согласен с этим утверждением, но как мне кажется, если данные требуют предварительной обработки, то ее проще произвести на Python, а возможности R использовать при необходимости именно для анализа.
Кроме этого, будет показано как интегрировать результаты выдачи работы функции R в IPython Notebook.

Инфраструктура системы пакетов для Python долго подвергалась критике как от разработчиков, так и от системных администраторов. Долгое время даже само комьюнити не могло прийти к соглашению, какие именно инструменты использовать в каждом конкретном случае. Уже существуют distutils, setuptools, distribute, distutils2 в качестве базовых механизмов распространения и virtualenv, buildout, easy_install и pip в качестве высокоуровневых инструментов управления всем этим беспорядком.

До setuptools основным форматом распространения были исходные файлы или некоторые бинарные MSI-дистрибутивы для Windows. Под Linux были изначально сломанный bdist_dumb и bdist_rpm, который работал только на системах, основанных на Red Hat. Но даже bdist_rpm работал недостаточно хорошо для того, чтобы люди начали его использовать.

Несколько лет назад PJE попытался исправить эту проблему, предоставив смесь из setuptools и pkg_resources для улучшения distutils и добавления метаданных в Python-пакеты. В дополнение к этому он написал утилиту easy_install для их установки. По причине отсутствия формата распространения, поддерживающего метаданные, был предоставлен формат 'яиц' [egg].

Python eggs – обычные zip-архивы, содержащие python-пакет и необходимые метаданные. Хотя многие люди, вероятно, никогда намеренно не собирали egg'и, их формат метаданных до сих пор жив-здоров. И все разворачивают свои проекты с использованием setuptools.

К сожалению, некоторое время спустя сообщество разделилось, и часть его провозгласила смерть бинарных форматов и 'яиц' в частности. После этого pip, замена easy_install, перестал принимать egg-формат.

Потом прошло еще немного времени, и отказ от бинарных пакетов стал доставлять неудобства. Люди всё больше и больше стали деплоить на облачные сервера, а необходимость перекомпиляции C-шных библиотек на каждой машине не слишком радует. Так как 'яйца' на тот момент были малопонятны (я так полагаю), их переделали в новых PEP-ах, и назвали 'колёсами' [wheels].

Давным давно был язык С. И были в нем 2 функции управляющие памятью — malloc и free. Но это было слишком сложно.
Посмотрел на это Бьёрн Страуструп и решил что нужно сделать все проще. И изобрел С++. В дополнение к malloc/free там появились new/delete, деструкторы, RAII, auto и shared указатели.
Посмотрел на это Гвидо ван Россум, и решил, что С++ тоже не достаточно прост. Он решил идти другим путем и придумал Python, в котором даже malloc и free нет.
А тем временем норвежские троли создали на С++ GUI-библиотеку Qt, которая упрощает управление памятью для своих объектов за счет того, что сама их удаляет, когда посчитает нужным.
Phil Thompson расстроился, что отличной библиотеки Qt нету для замечательного языка Python. И решил их объединить проектом PyQt. Однако, как оказалось, если скрестить разные парадигмы управления памятью, обязательно вылезут побочные эффекты. Давайте посмотрим какие…

Не раз слышал от своих знакомых, что было бы неплохо увидеть сайт который будет мониторить наличие свободных мест на ржд. Про себя я думал — «да неплохо бы» и благополучно забывал, но пост заставил меня вспомнить навыки копи паста, которыми я владею в совершенстве и обернуть это дело в питонячий код. Сразу оговорюсь что именно про мониторинг будет во второй части, а в этой будет про то: как ходить на РЖД из питона, что это за загадочный sleep про который писали в предыдущем посту и как живется на Google App Engine. Итак приступим:

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

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

Мобильная версия

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

Просьба! Мне бы хотелось перенести инструмент создания дайджеста на какой-нибудь более python-related домен. Может кто-нибудь поможет денежкой (600р. в год) или сам купит домен и делегирует на мой хостинг? Не хаброжители могут написать мне по этому поводу (да и любым другим) в скайп: alrusdi
На год уже есть спасибо inetava
И продление на второй год спасибо vaal

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

Питон изумителен.

Удивительно, но это довольно неоднозначное заявление. Что я имею ввиду под “Питоном”? Может, абстрактный интерфейс Питона? Или CPython, распространенная реализация Питона (не путать с похожим по названию Cython)? Или я имею ввиду что-то совсем иное? Может, я косвенно ссылаюсь на Jython, или IronPython, или PyPy. Или может я отвлекся так сильно, что говорю о RPython или RubyPython (которые очень сильно отличаются).

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

При работе с Питоном я столкнулся с кучей таких технологий. Инструменты *ython. Но лишь недавно я уделил время, чтобы разобраться, что они собой представляют, как они работают и почему они (каждая по-своему) необходимы.

В этом посте я начну с нуля и пройдусь по разным реализациям Питона, а закончу подробным введением в PyPy, за которым, по моему мнению, будущее языка.

Все начинается с понимания того, чем на самом деле является “Питон”.

В предыдущих трех частях мы создали лексер, парсер и AST для нашего игрушечного языка IMP. Мы даже написали нашу собственную библиотеку парсеров комбинаторов. В этой, финальной статье мы напишем последний компонент интерпретатора — исполнитель.


Давайте подумаем, как обычно исполняются программы. В любой момент времени есть некоторые «точки контроля», которые указывает на то, какое выражение программа собирается выполнить дальше. Когда следующее выражение исполняется, оно модифицирует состояние программы, путем улучшения «точки контроля» и изменения значений переменных.

Юбилейный, десятый выпуск свежих новостей о python и близлежащих технологиях интересен тем, что некоторые новости были добавлены в него через введенную хабраюзером axce1 форму добавления новости незарегистрированными пользователями. Очень приятно, что она начинает работать. Присоединяйтесь!

Есть неболшая тонкость, которую стоит разъяснить. Мне прислали ссылку на замечательную статью исследование объектов кода, но в выпуск она не попала, так как написана в марте прошлого года, то есть новостью по сути не является.

Спасибо owlman за то, что несмотря на несвоевременно предоставленную мной информацию о приоритетных новостях он все же нарисовал иллюстрацию.

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

Предыстория

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

В первую очередь, нам хотелось иметь ограниченный компактный набор конечных распространяемых модулей. Однако публичная сборка питона, распространяемая через python.org к этому не располагает, одна только стандартная библиотека, являющаяся неотъемлемой частью самого языка, состоит из более чем тысячи py-файлов. Именно поэтому, мы сразу обратили внимание на такую любопытную особенность интерпретатора, как возможность импорта модулей, находящихся в zip-архивах, когда все множество исходников на питоне, относящихся к одному или нескольким модулям, упаковано в zip-архив и распространяется одним zip-файлом.

До сих пор во многих компаниях deploy создает большие проблемы и может занимать дни, недели и в особо запущенных случаях месяцы. Но ситуация не безнадежна. Существует много инструментов и практик, способных помочь в этом нелегком деле. Вот только эти инструменты чаще всего за один-два дня не освоишь, а сроки горят.

Чего обычно хочется:

• Возможность поднять проект локально на машине разработчика. Весь или хотя бы частями. Причем очень хочется, чтобы Dev конфигурация отличалась от Prod в минимуме параметров. Это позволит избежать “work on my machine” багов. Да и вообще, когда один разработчик работает на OS X, другой на Windows, а продакшен на Debian, то жди беды, это не считая того, что каждый делает работу по настройке окружения.
• Dev конфигурацию хочется разворачивать на любой машине и ОС в пару команд в консоли. Это опять же позволит уменьшить фактор “work on my machine” багов. А еще позволит привлекать других разработчиков в проект за минимальное время (vagrant up и поехали).
• Конфигурация должна быть понятна и программисту, и админу.

Всего этого мы добьемся на связке Salt + Vagrant на примере Django проекта. Но большинство техник будут полезны разработчикам не только на Python, но на других языках.

Таким образом, мы написали лексер библиотеку комбинатора парсеров для нашего интерпретатора. В этой части, мы создадим структурные данные абстрактного синтаксического дерева (AST), и напишем парсер, используя нашу библиотеку комбинаторов, которые переводят список токенов, возвращенных лексером, в абстрактное синтаксическое дерево (AST). После того, как мы распарсим AST, запустить программу будет очень просто.

В статье мы постараемся классифицировать злокачественную опухоль груди от доброкачественной основываясь на наборе данных взятом отсюда. Как бы странно не звучало, но точность не будет главным приоритетом в этот раз, так как уже есть довольно хорошие решения с упором именно на точность, что и понятно, ведь от данных тестов зависит жизнь человека. Например в 2012 году Бриттани Венгер победила в конкурсе Google Science Fair с проектом cloud4cancer.appspot.com, который был обучен именно по выше указанному набору.

Доброго времени суток, хабровчане!


Думаю многих из вас когда-либо посещала мысль «вот бы сохранить статьи с Хабра».
Такая же мысль посетила и меня два дня назад. Сохранить захотел не просто каждую статью, а только те, что в избранном, да не поштучно, а сразу всё скопом.
Первая мысль — надо написать скрипт, который всё это вытянет. Python я уже подучил, но вот с генерацией PDF на нем сталкиваться ещё не приходилось.

Закручинился я было… Но OpenSource и Хабр спасли меня!

Доброе время суток, уважаемое хабрасообщество!

Скоро будет год, как я играю на геймпаде в World of Tanks, если кто-то пропустил мимо, как я выбирал первый в своей жизни ПК для игры прошу сюда.

Играть геймпадом интересно, но разработчики не хотят официально поддерживать его, соответственно приходится всячески извращаться для получения «некоего функционала».

От переводчика: Armin Ronacher довольно известный разработчик в Python-сообществе(Flask,jinja2,werkzeug).
Он довольно давно начал своеобразный крестовый поход против Python3, но обвинить его в истерике и ретроградстве не так-то просто: его возражения продиктованы серьезным опытом разработки, он довольно подробно аргументирует свою точку зрения. Немного о терминологии:
coercion я перевел как принудительное преобразование кодировок, а byte string как байтовые строки, так как термин «сырые» строки(raw string) все же означает несколько иное.
«Историческое» примечание: в 2012 г. Армин предложил PEP 414, который содержал ряд мер по устранению проблем с Unicode, PEP подтвердили довольно быстро, однако воз и ныне там, так как нижеприведенный текст написан 5 января 2014 года

Все труднее становиться вести обоснованную дискуссию о различиях между Python 2 и 3, так как один язык уже мертв,
а второй активно развивается. Когда кто-либо начинает обсуждение поддержки Unicode в двух ветках Python — это весьма сложная тема. Вместо рассмотрения поддержки Unicode в двух версиях языка, я рассмотрю базовую модель обработки текста и байтовых строк.

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

def customlogic(params):
    return params[0] and params[1] and not params[5] and params[11] or params[2] and not params[3] or params[0] and params[5] and not params[6] or params[7] and not params[8]

В конце статьи алгоритм проверяется на данных полученных из реального мира.

Python — красивый и местами загадочный язык. И даже зная его весьма неплохо, рано или поздно находишь для себя нечто такое, что раньше не использовал. Этот пост отражает некоторые детали языка, на которые многие не обращают внимание. Сразу скажу: многие примеры являются непрактичными, но, оттого, не менее интересными. Так же, многие примеры демонстрируют unpythonic стиль, но я и не претендую на новые стандарты — я просто хочу показать, что можно делать вот так.

Всвязи с наступающим 2014 годом от Рождества Христова может возникнуть вопрос: «А какой же на самом деле сейчас год без привязки к религиям?» На него я постараюсь ответить, а точнее показать, как это можно довольно легко вычислить, не слезая со стула.

Считать будем от момента начала Вселенной, то есть Большого Взрыва. Многие оговорки я буду опускать для получения результата за минимальное количество формул и строчек кода (да-да, мы будем программировать на Питоне!). В качестве бонуса мы также прикинем сколько тёмной энергии у нас во Вселенной.


Supernova 1994D as seen with the Hubble Space Telescope. Foto: Pete Chalis — Harvard Smithsonian Center of Astrophysics

Любопытно? Тогда поехали!

Неожиданно обнаружил, что интернет-магазин books.ru в преддверии Нового Года снова запустил акцию по продаже электронных книг по свободной цене. Акция продлится до 2 января. За списком интересных по моему мнению предложений прошу пожаловать под хабракат.