Собрали в одном месте самые важные ссылки
читайте авторский блог
Говорят, что отличный результат для мужчины — построить дом, вырастить сына и посадить дерево. А если ты программист, то ещё написать свой язык программирования.
Сейчас уже нет чисто интерпретируемых языков, даже Python сначала компилируется в байт-код, а потом интерпретируется — исполняется. Но как это он делает?
Чтобы узнать магию внутренностей интерпретаторов предлагаю цикл статей Let’s Build A Simple Interpreter:
Обязательное действие перед выпуском более-менее серьёзного проекта — тестирование производительности. На высоконагруженных проектах нужно точно знать, какую нагрузку они могут выдержать, причём заранее. Следовательно, нужен способ эмуляции высокой конкурентности, желательно чтобы в теории он позволял полностью загрузить канал траффиком. К тому же, неплохо было бы, чтобы для этого не нужно было использовать несколько десятков серверов. В докладе будет рассказано об опыте использования gevent для подобной задачи, что позволило бы обойтись одним t1.micro инстансом, с которого выполняется тестирование.
Чем больше/непонятней сайт, тем чаще используют поиск. В докладе Андрея Солдатенко вы сможете узнать как организовать хороший поиск по вашему сайту
Чем Python и его экосистема отличается от других языков программирования? Какая у Python ниша? Какие сильные и слабые стороны у языка и батареек? На все эти вопросы Григорий попробует ответить в своём обзорном докладе, рассказывающем о том, куда ползёт Python в 2015 году
ython 2 и проблемы с кодировками — это единое целое. И мало, что сами файлы с исходниками сохраняют в самых разных кодировках, так и текстовые файлы с данными этим грешат. Казалось бы, используйencode/decode и что тут думать. Но бывает, что декодируешь юникод и получаешь строку:
u'\xd0\x9a\xd1\x83\xd1\x80\xd1\x83\xd0\xbc\xd0\xbe\xd1\x87'
Еще в далеком Python 2.3 был добавлен модуль zipimport. Этот модуль упростил возможность импорта изzip файлов:
Представим мы придумали алгоритм, на пальцах оценили его быстродействие, закодили и получили медленно работающий софт. Что делать? куда бежать? С чего стоит начать? Да сначала стоит измерить сколько ресурсов (память, время, проц) кушает ваш софт. Уже имея числа на руках можно думать дальше. Для измерения временных затрат для вашего кода можно воспользоваться библиотекой timeit. А другие ресурсы измерим в след. раз. Она позволяет измерить время работы куска кода программы:
Списки - встроенный тип Python, могут содержать любые элементы: целые, дробные числа, строки, объекты. Это великая сила Python, но в то же время и слабость — в отношении скорости работы. В стандартные дистрибутивы Python входит модуль array, реализующий аналог массивов C/C++, он может пригодиться для простейших расчётов с многомерными массивами, матрицами. NumPy — мощнейшая библиотека для научных вычислений. Написать здесь операции с матрицами так же просто, как и с обычными числами. Матрица в NumPy — это объект numpy.array, массив чисел одного типа, какой угодно размерности: 0 (одно число, скаляр), 1 (вектор), 2 (матрица), 3 (тензор третьего ранга)...
Когда полезны аннотации типов? Станет ли асинхронное программирование обычной практикой с новыми async-await? Устроим обсуждение этих и других новинок Python 3.5. Все это вы сможете узнаете в докладе Андрея Власовских
PEP 484 добавил в Python расширенные возможности опциональной типизации. Польза от этого функционала большая - возможность создать статический анализатор Python программ, а значит еще до запуска узнать об многих ошибках.
Появился модуль typing, который в 3.5 есть по умолчанию, а начиная с 3.2 можно установить с PyPi Но что делать с кодом на 2.7? Хочется же больше ошибок вылавливать. Здесь на пользу приходят python stubs - .pyiфайлы.
Слышали фразу: "Если что-то выглядит как утка, плавает как утка и крякает как утка, то, вероятно, это утка"? Эта поговорка характеризует утиную типизацию == утипизацию
Смысл утиной типизации заключается в ослаблении типов. Вместо того чтобы заботиться о точном классе объекта мы заботимся о том какие методы для него можно вызвать и какие операции над ним можно выполнять. Таким образом, обычным делом становится просто передать объект методу, зная, что при неправильном использовании будет выброшено исключение (exception).
Django - web-фреймворк. Обладает отличной документацией, которую можно читать долго и упорно. Есть даже тутроиал по созданию блога. Вот только есть "минус" - проходишь туториал с блогом и не знаешь где еще добыть структурированной информации. Да еще и актуальной.
Синтаксис Python легкий, читаемый. Хочется упомянуть массивы (как структура с последовательными элементами). В Python они бывают разные - list, tuple, строки Операции с массивами:
Вы наверное слышали фразу "wild import - зло". В коде это выглядит так
from my_super_module import *
Ответ почему это "зло" очень простой - вы импортируете всё - то что надо и то что не надо. А значит вы можете смело перегрузить какой-то метод. Как же быть? Можно импортировать только нужные переменные и функции/классы, что является правильным подходом. Но ведь должен быть альтернативный вариант.
ООП преподают везде. В школе, в универе, в колледже, на курсах, упоминают в статьях, есть даже много книг на эту тему - например, банда четырех. Важным моментом ОО это паттерны. Это набор узаконенных хитростей и хаков, которые позволяют обходить недостатки самого ООП. По ссылкеhttps://github.com/faif/python-patterns вы сможете найти готовый код для множества паттернов.
Хорошие имена переменных - это признак хорошего кода. Для циклов часто используют одно-буквенные переменные, для временных переменных тоже короткие, для глобальных - ЗАГЛАВНЫЕ. Есть и другие рекомендации. Все они написаны кровью из глаз разработчиков.
Перейдем к заголовку и сразу пример: Пускай есть функция, которая возвращает 3 значения...
Наверное, вы слышали про модуль Pickle, который умеет сериализовать объект в бинарный вид, который можно потом сохранить/загрузить в /из файл.
А модуль marshal сериализует объект в текстовый вид. Получив строку вы можете отправить ее другу по email, а уже из строки снова получить объект
Тестирование программ повышает уверенность в ее способности работать. Есть даже большие школы, которые говорят о тестах, например, TDD, BDD.
У ручных тестов есть недостаток, среди прочих - тесты пишет человек. В следствии этого - он не сможет проверить работу функции/класса/etc на всех данных. А когда нам быть уверенным что даже на самых невалидных данных работает корректно, то без случайных данных не обойтись.
Ситуация: написали web-проект, свой, домашний, а может и на работе. Надо его опубликовать в Интернет - задеплоить. Зашли на сервер, активировали venv, скачали новые исходники из репозитория, накатили миграции, обновили static-файлы, перезапустили, предположим, celery, перезапустили uwsgi.
И тут, поняли что забыли раскоментировать строчку в коде. Делаем коммит, снова заходим на сервер, активировали venv.... Зачем вся эта рутина с деплоем? Может есть способ проще? Мы же IT-шники, давайте напишем скрипт.
В Интернет часто говорят об ООП, об объектах. Так какой смысл во всем этом? Какая польза, недостатки? Соображения на эту темы вы сможете найти в видео: