Архив метки: Python

Слайды с PyCon RU

Слайды с моего доклада на PyCon RU можно просмотреть здесь.

Автор: Andrew Svetlov

Исключения в Питоне

Поговорим об исключениях.

Всё нижеизложенное относится к Python 3.3, хотя отчасти справедливо и для более ранних версий.

Для чего они применяются, наверное, все и так прекрасно знают: для передачи сообщений об ошибках внутри программы.

Рассмотрим простейший пример: открытие файла. Если всё нормально — open(filename, 'r') возвращает объект этого самого файла, с которым можно делать всякие полезные вещи: читать из него данные и т.д.

Если файл не может быть открыт — выбрасывается исключение:

try:
    f = open(filename, 'r')
    try:
        print(f.read())
    finally:
        f.close()
except OSError as ex:
    print("Cannot process file", filename, ": Error is", ex)

Открываем файл и печатаем его содержимое.

Обратите внимание: файл нужно не только открыть но и закрыть после использования. Исключение может выбросить open (например, если файла нет на диске или нет прав на его чтение).

Если файл открыт — читаем его через f.read(). Этот вызов тоже может выбросить исключение, но файл закрывать всё равно нужно. Поэтому необходим блок finally: f.close() должен быть вызван даже если f.read() сломался. В этом месте удобней было бы воспользоваться конструкцией with но мы же сейчас говорим об исключениях а не о контекстных менеджерах, верно?

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

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

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

Типы исключений

Все исключения составляют иерархию с простым наследованием. Вот простой небольшой кусочек от довольно обширного набора исключений ядра Питона:

BaseException
 +-- SystemExit
 +-- KeyboardInterrupt
 +-- GeneratorExit
 +-- Exception
      +-- StopIteration
      +-- AssertionError
      +-- AttributeError
      +-- BufferError

Самый базовый класс — BaseException. Он и его простые потомки (SystemExit, KeyboardInterrupt, GeneratorExit) не предназначены для перехвата обыкновенным программистом — только Питон и редкие библиотеки должны работать с этими типами. Нарушение правила ведет, например, к тому что программу невозможно корректно завершить — что совсем не хорошо.

Также не нужно перехватывать все исключения:

try:
    ...
except:
    ...

работает как

try:
    ...
except BaseException:
    ...

Всё, что может быть нужно программисту — это Exception и унаследованные от него классы.

Вообще-то лучше ловить как можно более конкретные классы исключений. Например, в случае с файлом это OSError или даже может быть FileNotFoundError. Таким образом мы не перехватим AttributeErrorили ValueError, которые в этом примере означали бы ошибку или опечатку программиста.

Кстати, обратите внимание: StopIteration порожден от Exception а GeneratorExit от BaseException. Подробности, почему сделано именно так, можно найти в PEP 342.

Цепочки исключений

Прочитав предыдущую главку все прониклись необходимостью указывать правильный класс исключений и пообещали никогда не использовать BaseException.

Идем дальше. Следующий пример:

try:
    user = get_user_from_db(login)
except DBError as ex:
    raise UserNotFoundError(login) from ex

Получаем пользователя из базы данных чтобы что-то потом с ним сделать. get_user_from_db может выбросить ошибку базы данных. Для нас это скорее всего означает что такого пользователя нет. Но для логики приложения полезней наш собственный тип UserNotFoundError с указанием логина проблемного пользователя, а не обезличенная ошибка БД — что мы и выбрасываем в обработчике исключения.

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

Для таких целей служит конструкция raise ... from ....

По PEP 3134 у объекта исключения имеется несколько обязательных атрибутов.

В первую очередь это __traceback__, содержащий кусочек стека от места возникновения исключения до места его обработки.

Затем — __context__. Если исключение было создано в ходе обработки другого исключения (выброшено из except блока) — __context__будет содержать то самое породившее исключение. Которое, в свою очередь тоже может иметь установленный __context__. Этот атрибут равен None если наше исключение — самое первое и н
е имеет предшественников.

__context__ устанавливается автоматически.

В отличие от контекста __cause__ устанавливается только если исключение было выброшено конструкцией raise ... from ... и равно значению from.

Если исключение выбрасывалось простым raise ... то __cause__ будет равно None в то время как __context__ всегда будет содержать породившее исключение если оно существует.

Для вывода исключения со всей информацией служит набор функций из модуля traceback, например traceback.print_exc().

И тут тоже есть проблема: печатается либо явная цепочка если есть установленный __cause__ или неявная, тогда используется __context__.

Иногда программисту может быть нужно отбросить породившие исключения как не имеющие смысла при выводе traceback. Для этого появилась форма записи

raise exc from None

PEP 409 и PEP 415 рассказывают как это работает:

У исключения всегда есть атрибут __supress_context__. По умолчанию он равен False.

Конструкция raise ... from ... записывает fromв __cause__ и устанавливает __supress_context__ в True.

Тогда семейство функций traceback.print_exc() печатают цепочку если явно указан (не равен None) __cause__ или есть __context__ и при этом __supress_context__ равен False.

Изложение получилось несколько длинным, но сократить текст без потери смысла у меня не вышло.

Семейство OSError

Последняя проблема о которой хотелось бы рассказать — это типы исключений порожденные вызовами операционной системы.

До Python 3.3 существовало много разных типов таких исключений: os.error, socket.error, IOError, WindowsError, select.errorи т.д.

Это приводило к тому, что приходилось указывать несколько типов обрабатываемых исключений одновременно:

try:
    do_something()
except (os.error, IOError) as ex:
    pass

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

Проблема решена в PEP 3151: весь этот зоопарк теперь является псевдонимами для OSError. Т.е. пишите OSError и не ошибетесь (прочие имена оставлены для обратной совместимости и облегчения портирования кода на новую версию).

Давайте рассмотрим ещё один аспект исключений, порожденных операционной системой.

У OSError есть атрибут errno, который содержит код ошибки (список всех возможных символьных констант для ошибок можно посмотреть в модуле errno).

Открываем файл, получаем OSError в ответ. Раньше мы должны были анализировать ex.errno чтобы понять, отчего произошла ошибка: может файла нет на диске, а может нет прав на запись — это разные коды ошибок (ENOENT если файла нет и EACCES или EPERM если нет прав).

Приходилось строить конструкцию вроде следующей:

try:
    f = open(filename)
except OSError as ex:
    if ex.errno == errno.ENOENT:
       handle_file_not_found(filename)
    elif ex.errno in (errno.EACCES, errno.EPERM):
       handle_no_perm(filename)
    else:
       raise  # обязательно выбрасывать не обработанные коды ошибки

Теперь иерархия расширилась. Привожу полный список наследников OSError:

OSError
 +-- BlockingIOError
 +-- ChildProcessError
 +-- ConnectionError
 |    +-- BrokenPipeError
 |    +-- ConnectionAbortedError
 |    +-- ConnectionRefusedError
 |    +-- ConnectionResetError
 +-- FileExistsError
 +-- FileNotFoundError
 +-- InterruptedError
 +-- IsADirectoryError
 +-- NotADirectoryError
 +-- PermissionError
 +-- ProcessLookupError
 +-- TimeoutError

Наш пример можем переписать как:

try:
    f = open(filename)
except FileNotFound as ex:
    handle_file_not_found(filename)
except PermissionError as ex:
    handle_no_perm(filename)

Гораздо проще и понятней, правда? И меньше мест, где программист может ошибиться.

Заключение

Переходите на Python 3.3, если можете. Он хороший и облегчает жизнь.

Новые плюшки в вопросе, касающемся исключений, я показал.

Если использовать новый питон не позволяют обстоятельства — пишите на чём есть, но помните как правильно это делать.

Автор: Andrew Svetlov

Зачем в python with

Долгое время при работе с файлами из python я писал примерно следующий код:

Без подсветки синтаксиса

def some_func(fname):
    fd = open(fname)
    some_data_processing(fd.read())
    return result

def some_func(fname):
    fd = open(fname)
    some_data_processing(fd.read())
    return result

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

Но что будет если в some_data_processing произойдет исключение?

Например так:

Без подсветки синтаксиса

import sys

class TestClass(object):
def __del__(self):
print «I’m deleted»

def data_process():
obj = TestClass()
raise IndexError()

try:
data_process()
except:
print «In exception handler»

print «after except»

import sys

class TestClass(object):
def __del__(self):
print «I’m deleted»

def data_process():
obj = TestClass()
raise IndexError()

try:
data_process()
except:
print «In exception handler»

print «after except»

На консоли появляется:

    In exception handler
    after except
    I'm deleted

Почему-то «In exception handler» и «after except» выводятся раньше «I’m deleted».

Первая проблема в том, что вместе с исключением питон хранит и трейс стека, содержащий все фреймы вплоть до породившего исключение. А внутри фрейма живет f_locals — словарь локальных переменных, и именно он имеет ссылку на экземпляр класса TestClass. Таким образом до окончания обработки исключения obj будет жить точно. Почему же «after except» появляется раньше чем «I’m deleted»? Было бы логично чистить трейс после успешного выхода из блока try. Дело в том что 2.X питон не всегда чистит внутренние структуры после обработки исключения и в общем случае вы должны явно вызывать функцию sys.exc_clear чтобы очистить их. Когда я подошел с этим вопросом к Larry Hastings (одному из основных разработчиков ядра питона) ему потребовалось около 20ти минут, что-бы понять что происходит и найти в документации sys.exc_clear. (Правда стоит отметить, что он давно использует 3.X, где это поведение стало адекватнее.) В 3.X это поведение улучшили, и теперь sys.exc_clear автоматически вызывается окончанию обработки исключения.

Кстати, если вы напишете примерно такой код:

Без подсветки синтаксиса

try:
    data_process()
except:
    fr = sys.exc_info()[2]
    del fr

try:
    data_process()
except:
    fr = sys.exc_info()[2]
    del fr

то не забудьте удалить fr используя del, как в последней строке — иначе он образует циклическую ссылку с текущим фреймом и тогда все станет совсем плохо.

Стоит отметить, что подобное поведение проявляется не всегда. Например сл

Lviv.py #0

Видео и презентация с lviv.py, где я рассказывал о новом механизме импорта, который появился в Python 3.3
Видео — первая часть, вторая часть и презентация.

Автор: Andrew Svetlov

Метаклассы в python 2.X с примерами и полным разоблачением

Теория, часть 1. Метаклассы

Все начинается с объявления класса:

Hightlited/Raw

class A(object):
    field = 12
    def method(self, param):
        return param + self.field

class A(object):
    field = 12
    def method(self, param):
        return param + self.field

Имеющие опыт программирования на компилируемых языках могут увидеть здесь декларативную конструкцию, но это только обман зрения. В python всего две декларативные конструкции — объявление кодировки файла и импорт синтаксических конструкций «из будущего». Все остальное — исполняемое. Написанное объявление это синтаксический сахар для следующего:

Hightlited/Raw

txt_code = """
field = 12
def method(self, param):
    return param + self.field
"""

class_body = {}
compiled_code = compile(txt_code, __file__, "exec")
eval(compiled_code, globals(), class_body)
A = type("A", (object,), class_body)

txt_code = """
field = 12
def method(self, param):
    return param + self.field
"""

class_body = {}
compiled_code = compile(txt_code, __file__, "exec")
eval(compiled_code, globals(), class_body)
A = type("A", (object,), class_body)

Оба этих способа создать класс A совершенно эквивалентны. Окончательно убедиться в том, что объявление класса исполнимо можно посмотрев вот на это:

Hightlited/Raw

def this_is_not_cplusplus(some_base_class, num_methods):
    class Result(some_base_class):
        x = some_base_class()
        for pos in range(num_methods):
            # добавим функцию в locals - она попадает в тело 
            # класса Result и станет его методом
            locals()['method_' + str(pos)] = 
                    lambda self, m : m + num_methods
    return Result

class_with_10_methods = this_is_not_cplusplus(object, 10)
class_with_20_methods = this_is_not_cplusplus(
                            class_with_10_methods, 20)
print class_with_10_methods().method_3(2) # напечатает 12
print class_with_20_methods().method_13(2) # напечатает 22

def this_is_not_cplusplus(some_base_class, num_methods):
    class Result(some_base_class):
        x = some_base_class()
        for pos in range(num_methods):
            # добавим функцию в locals - она попадает в тело 
            # класса Result и станет его методом
            locals()['method_' + str(pos)] = 
                    lambda self, m : m + num_methods
    return Result

class_with_10_methods = this_is_not_cplusplus(object, 10)
class_with_20_methods = this_is_not_cplusplus(
                            class_with_10_methods, 20)
print class_with_10_methods().method_3(2) # напечатает 12
print class_with_20_methods().method_13(2) # напечатает 22

Функция this_is_not_cplusplus создает новый класс каждый раз, когда мы ее вызываем, используя переданный тип в качестве базового и создавая в н

Установка питона и пакетов

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

Задачи обычно возникающие при установки питона и его пакетов:

Выбор дистрибутив питона и его установка
Выбор IDE
Поиск и установка пакетов

Кроме этого я пробегусь по этим полезным вещам:

virtualenv
lint’ы
ipython
pythonanywhere.com

Выбор дистрибутив питона и его установка

Если вы используете linux, то лучше использовать python идущий в пакетах — как правило это немного измененный cpython. Для windows можно выбирать между стандартным питоном и дистрибутивом от Active State. Последний содержит расширенную документацию и некоторые дополнительные библиотеки. Мы не будем рассматривать PyPy/Stackless/etc — ограничимся только CPython. Дальше нужно сделать выбор между двумя ветками — 3.2/3.3 и 2.7. Пока что с 2.7 у вас будет меньше проблем, но третья версия по поддержке уже подбирается достаточно близко. x86 и amd64 версии выбираем по вкусу. Установка и под windows и совершенно стандартна и не должна вызывать проблем. В linux питон уже почти 100% установлен.

Выбор IDE

Динамический характер языка делает написание функциональных IDE достаточно сложным, а высокая компактность кода и pythonic подход заметно уменьшает в них необходимость. Так что не сложные проекты можно делать в продвинутых текстовых редакторах — [notepad++], sublime text (или vim/emacs). Хотя новичкам IDE будут оказывать заметную помошь встроенной подсказкой и каким ни каким статическим анализом. Из IDE я бы выделил eclipse + pydev и платные PyCharm и KomodoIDE. Также есть Python tools for VS, которые добавляет поддержку cpython и ironpython в VS2010/VS2012.

Я бы советовал выбирать между sublime text и eclipse + pydev.

Поиск и установка пакетов

Пакеты/модули в python это файлы с расширениями py/pyc/pyo/(pyd или so), или директории с такими файлами. Также весь пакет может быть в одном архиве (только если пакет не содержит pyd/so файлы). По умолчанию пакеты устанавливаются в системную папку — PYTHON_ROOTlibsite-packages для windows и /usr/local/lib/pythonXX/dist-packages для ubuntu (XX — версия питона, PYTHON_ROOT — корневая папка установки python, как правило С:PythonXX)

Если вы используете linux, то можно использовать пакеты из дистрибутива — в Ubuntu/Fedora есть практически все. Иначе искать пакеты в основном стоит на pypi или с помощью google. Пакеты могут быть в трех основных форматах: архив, exe/msi, egg.

Архив нужно распаковать, в корневой папке должен быть файл setup.py. Если его там нет, то можно просто скопировать содержимое архива в директорию с пакетами. Если setup.py есть, то нужно выполнить python setup.py install. При этом следует использовать тот интерпретатор питона, в который вы хотите установить пакет. Если пакет не предоставляет модулей написанных на С/С++, то установка должна пройти без особенных проблем. Иначе python будет пытаться собрать компилируемые расширения. В linux такой процесс проходит чаще всего безболезненно (максимум требуется установка пакетов с заголовочными файлами для для используемых C библиотек), а вот в windows путь компиляции может быть достаточно трудным.

При установке в windows проще использовать уже собранный exe/msi файл. Для большинства пакетов они доступны на pypi или на сайте библиотеки, также много бинарных пакетов можно найти на pythonlibs. При загрузке обратите внимание на архитектуру и версию python. Для установки такие пакеты нужно запустить. Библиотеки не содержащие компилируемого кода уставливаются без проблем на обеих системах.

egg это формат пакетов одного из пакетные менеджеров питона — setuptools. Грубо говоря это zip архив с дополнительной информацией о пакете и его зависимостях. Более новой и активно развиваемой альтернативой setuptools является pip. pip использует код setuptools(или distribute) и не поддерживает egg. Оба этих менеджера умеют находить пакеты по имени на pypi, по URL и локально. Поддерживаются разнообразные форматы архивов и автоматическая установка зависимостей. pip умеет деинсталлировать пакеты и поддерживает установку из svn/git/mercurial.

Установка pip — www.pip-installer.org/en/latest/installing.html

скачать и запустить python-distribute.org/distribute_setup.py
скачать и запустить raw.github.com/pypa/pip/master/contrib/get-pip.py

Установка setuptools

Скачать и запустить peak.telecommunity.com/dist/ez_setup.py

Оба этих менеджера предоставляют команду easy_install, pip кроме этого предоставляет команду pip.

Использование (примеры команд без их вывода):

Без подсветки синтаксиса

# pip install pylint # установим pylint
# easy_install install -U pylint # обновить пакет
# pip install --upgrade simplejson
# pip uninstall simplejson # удалить
# pip install http://my.package.repo/SomePackage-1.0.4.zip
# pip install git+https://github.com/simplejson/simplejson.git
# pip install svn+svn://svn.zope.org/repos/main/zope.interface/trunk/

# pip install pylint # установим pylint
# easy_install install -U pylint # обновить пакет
# pip install --upgrade simplejson
# pip uninstall simplejson # удалить
# pip install http://my.package.repo/SomePackage-1.0.4.zip
# pip install git+https://github.com/simplejson/simplejson.git
# pip install svn+svn://svn.zope.org/repos/main/zope.interface/trunk/

virtualenv

virtualenv позволяет делать на одной машине несколько независимых инсталляций python, каждая из которых имеет свой интерпретатор, набор настроек и библиотек. Некоторые из таких окружений могут использовать системную папку с дополнительными пакетами. Кроме этого virtualenv позволяет устанавливать питон и пакеты пользователям без прав root.

Без подсветки синтаксиса

$ sudo pip install virtualenv # или sudo apt-get install python-virtualenv
$ virtualenv --distribute ENV_NAME # или python virtualenv.py --distribute ENV_NAME

—distribute заставить virtualenv установить distribute вместо setuptools.

$ sudo pip install virtualenv # или sudo apt-get install python-virtualenv
$ virtualenv --distribute ENV_NAME # или python virtualenv.py --distribute ENV_NAME

—distribute заставить virtualenv установить distribute вместо setuptools.

Эта команда создаст папку ENV_NAME внутри которой будет интерпретатор python ENV_NAME/bin/python и каталог для пакетов ENV_NAME/lib/pythonX.X/site-packages. ENV_NAME/bin/python будет настроен на поиск пакетов в ENV_NAME/lib/pythonX.X/site-packages. Также virtualenv устанавливает в новое окружение pip. Что-бы активировать это окружений нужно исполнить скрипт activate.

Без подсветки синтаксиса

$ source ENV_NAME/bin/activate
> ENV_NAMEScriptsactivate # для windows

$ source ENV_NAME/bin/activate
> ENV_NAMEScriptsactivate # для windows

Теперь команда python будет приводить к запуску питона из ENV_NAME/bin/python, то же относится и к pip. После окончания работы нужно выполнить deactivate. virtualenv включили в стандартную библиотеку начиная с python3.3

lint’ы

Линтами называют средства статического анализа по имени первой такой утилиты, которая находила странно написанные участки C кода, потенциально содержащие ошибки. Из-за динамического характера python сделать для него очень хороший линт невозможно, а даже просто хороший очень сложно. Ошибки при которых С программа даже не скомпилируется могут легко загнать в угол python линты. Но тем не менее значительную часть (а у начинающих — практически все) ошибок/опечаток они найдут.

Три основных lint’а для python это pylint, pychecker и pyflakes. Из них pylint, наверное, наиболее сообразительный. Кроме этого он имеет большое количество настроек, которые позволяют изменить особенности проверок. Также pylint проверяет стиль кода, используя шаблоны из конфигурационного файла и собирает полезную статистику. Плюс большая часть IDE и даже sublime имеют интеграцию с pylint.

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

Как более легкую альтернативу можно использовать pep8, проверяющий код на соответствие основному python стандарту кодирования.

ipython

Чуть подробнее о установке ipython. Под linux с правами root все просто (ubuntu):

Без подсветки синтаксиса

$ sudo apt-get install ipython ipython-doc ipython-notebook ipython-qtconsole python-zmq

$ sudo apt-get install ipython ipython-doc ipython-notebook ipython-qtconsole python-zmq

или

Без подсветки синтаксиса

$ sudo apt-get install --install-suggests ipython

$ sudo apt-get install --install-suggests ipython

ipython готов к запуску —

Без подсветки синтаксиса

$ ipython qtconsole # GUI консоль
$ ipython notebook  # Web интерфейс
$ ipython # консольный интерфейс

$ ipython qtconsole # GUI консоль
$ ipython notebook  # Web интерфейс
$ ipython # консольный интерфейс

Под windows все не так просто — нужно загрузить все пакеты и зависимости вручную и установить их. pip поможет не сильно, поскольку большая часть пакетов С расширения с внешними зависимости и собирать их будет лишней сложностью. Зависимости ipython (поскольку мы не будем использовать pip то их придется выяснять и устанавливать самостоятельно) можно определить двумя способами — найти в документации по установке или пытаться запускать ipython и смотреть на ошибки импорта. Из документации находим зависимости:

pyqt или pyside
pyzmq
tornado
pygments
pyreadline
distribute или setuptools

Бинарные версии всех этих пакетов есть в pythonlibs. Загружаем и ставим в любом порядке. После чего выбираем из:

Без подсветки синтаксиса

> С:Python2.7Scriptsipython.bat qtconsole # GUI консоль
> С:Python2.7Scriptsipython.bat notebook # Web интерфейс
> С:Python2.7Scriptsipython.bat # консольный интерфейс

> С:Python2.7Scriptsipython.bat qtconsole # GUI консоль
> С:Python2.7Scriptsipython.bat notebook # Web интерфейс
> С:Python2.7Scriptsipython.bat # консольный интерфейс

pythonanywhere.com

Если поставить питон совсем никак нельзя, то можно воспользоваться web консолью на указанном сайте. После регистрации можно бесплатно запустить 2 python/ipython консоли в браузере и пробовать python без установки.

Ссылки:
pypi.python.org/pypi/virtualenv
www.python.org/download
www.activestate.com/activepython/downloads
pypi.python.org/pypi
www.lfd.uci.edu/~gohlke/pythonlibs
www.pip-installer.org/en/latest/index.html
ipython.org/ipython-doc/stable/install/install.html
pychecker.sourceforge.net
pytools.codeplex.com
launchpad.net/pyflakes
www.python.org/dev/peps/pep-0008
pypi.python.org/pypi/pylint
pypi.python.org/pypi/pep8
www.jetbrains.com/pycharm
pydev.org
pypi.python.org/pypi/setuptools
www.sublimetext.com
www.activestate.com/komodo-ide
pythonanywhere.com

Исходники этого и других постов со скриптами лежат тут — github.com/koder-ua. При использовании их, пожалуйста, ссылайтесь на koder-ua.blogspot.com.

Автор: konstantin danilov

ReadMag.ru

рецепты по настройке программного обеспечения

Архив метки: Python

Слайды с PyCon RU

Исключения в Питоне

Типы исключений

Цепочки исключений

Семейство OSError

Заключение

Зачем в python with

Lviv.py #0

Метаклассы в python 2.X с примерами и полным разоблачением

Теория, часть 1. Метаклассы

Установка питона и пакетов

Выбор дистрибутив питона и его установка

Выбор IDE

Поиск и установка пакетов

virtualenv

lint’ы

ipython

pythonanywhere.com