Самые комментируемые за месяц

9 января 2012, 20:31

main() в программах на питоне

Почти все мои скрипты пишутся по этому шаблону:

# coding=utf-8

def main():
    pass # do main stuff
  

# here be functions and classes


if __name__ == '__main__':
    main()

Есть две причины. Во-первых, из-за if __name__ == '__main__': можно использовать скрипт и как самостоятельную программу (__name__ будет содержать '__main__' только когда скрипт запущен сам по себе, см. весьма краткий раздел документации ), и как модуль, при подключении которого определённый код исполнять не нужно. А во-вторых, лучше, когда главная часть программы идёт в начале файла. Благодаря правильно названным классам и функциям сразу становится ясно, что скрипт делает.

Сделать проще:

# coding=utf-8

if __name__ == '__main__':
    pass # do main stuff


# here be functions and classes

не получится по простой причине: в момент исполнения # do main stuff объекты, объявляемые в # functions and classes ещё не определены и интерпретатор не может их использовать.

11 февраля 2012, 17:05

Питон и производительность

Лучше один час писать программу, которая будет работать восемь часов, чем восемь часов писать программу, которая проработает час.

(Речь не идёт о взаимодействии с пользователем, интерфейс в любом случае должен работать быстро.)

11 мая 2012, 10:32

Повторение вопроса из зала

Стенфордские преподаватели курса CS 193P про программирование для iOS (я смотрел зимний 2010), перед тем, как отвечать на вопрос из зала, сначала повторяют его. Это решает минимум две задачи.

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

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

Кстати, после ответа преподаватель всегда спрашивает: «Я ответил на ваш вопрос?»

23 апреля 2012, 11:26

Медленнодействие

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

Подобное замедление появилось в Django 1.4.

Ещё один пример — проверка кода аутентичности сообщения. Алиса посылает Бобу сообщение (например, «Переведи 100 долларов на счёт 42») и специальный код (например «56789»), с помощью которого Боб убеждается, что сообщение пришло именно от Алисы и что сообщение по дороге не изменилось. Этот код зависит от ключа, который есть только у Алисы и Боба, поэтому враг не может просто так создать сообщение и код, которым Боб поверит. Обычно проверка происходит так: Боб берёт ключ и полученное сообщение, вычисляет код и сравнивает с присланным кодом.

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

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