company_banner

Python Meetup 26.09.14: cовершенствуем код и ускоряем Python

  • Tutorial
Белорусские Python’нщики верны своим традициям. Python Meetup состоялся 26 сентября, в последнюю пятницу месяца.
На встрече мы обсуждали извечную головную боль всех программистов – как писать красивый и понятный код без багов. Докладчики подошли к этой проблеме с разных сторон: Павел Кохан рассказал о пяти принципах S.O.L.I.D., которые помогают писать качественный код на любом объектно-ориентированном языке, а Олег Шидловский говорил о том, как ускорить работу хорошего кода.

Python Meetup

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

Павел Кохан «S.O.L.I.D.»
разработчик компании Runa Systems
S.O.L.I.D. – это аббревиатура, обозначающая 5 базовых принципов построения классов и наследования в объектно-ориентированном программировании. Использование S.O.L.I.D. может сильно упростить работу программиста. И дело не только в облегчении последующей поддержки и расширения кода. Использование этих принципов позволяет получить красивый, понятный код без багов в любом объектно-ориентированном языке программирования, не только в Python.
В своем докладе Павел, на примерах из Python, просто и доступно рассказал о каждом из принципов и полезности их применения.
Презентацию Павла вы можете посмотреть и скачать тут.




Олег Шидловский «Быстрые конструкции в Python»
Фрилансер, призер Всероссийской Командной олимпиады по программированию, призер Всероссийской индивидуальной олимпиады
Одним из основных недостатков Python многие специалисты считают его недостаточное быстродействие. И в какой-то степени это действительно так. Но на самом деле все зависит от разработчика. Олег показал несколько способов увеличить скорость Python, в частности, использование встроенных функций, которые вызываются намного быстрее глобальных.
Презентацию Олега вы можете посмотреть и скачать тут.




Следующий Python Meetup пройдет 31 октября.
На встрече доклады представят:
Максим Щепелин, Web Developer Wargaming
«Про асинхронность»
Олег Курьян, технический директор Экспанса Груп
«OpenSource CMS и ERP система в одном флаконе»
Павел Мешкой, Web Developer Wargaming
«Почему я пишу хороший код, но его никто не ценит, кроме моей мамы»

Ознакомится с подробной программой и зарегистрироваться можно тут.
  • +28
  • 13.8k
  • 8
Wargaming
88.55
Company
Share post

Similar posts

Comments 8

    +1
    Что-то начал я слушать про СОЛИД (впервые про него узнал), и какая-то каша там. Прямоугольник, квадрат, я сам не понял и т.д. Ну не понял — не рассказывай. Вообще ситуация с квадратом как родительским классом — странная. По всему должно быть, что квадрат — это чайлд прямоугольника, который чайлд многоугольника, который чайлд фигуры. Но я не программист, я не знаю. Вам виднее…
      +1
      Доклад я не смотрел, но попробую объяснить про прямоугольник и квадрат, как я понимаю эту проблему.

      Если мы говорим о статических прямоугольнике и квадрате (то есть таких, которые мы создаём один раз и не можем после менять), то никаких проблем нет: класс такого квадрата можно сделать потомком класса такого прямоугольника, и принципу LSP это противоречить не будет.

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

      Так вот, если в качестве базового класса мы возьмем динамический прямоугольник с инвариантными пропорциями, то динамический квадрат опять естественным образом делается его потомком — и никакого нарушения LSP! Динамический же прямоугольник общего вида, как ни странно, тоже можно сделать потомком того же базового класса, тогда он будет сиблингом (братом/сестрой) динамического квадрата.

      Тут нелишне, правда, заметить, что потомки-то они оба потомки, но на разных основаниях. Динамический квадрат потомок потому, что является частным случаем (subclass-of). А динамический прямоугольник общего вида потомок, потому что расширяет функциональность.
        0
        так в докладе говорится о том, что квадрат — это базовый класс для прямоугольника (а не его частный случай), так что с imwode я согласен, каша полнейшая. Очень хотелось уловить мысль докладчика, но не получилось.
        0
        Тоже ничего не понял, но если подумать, то квадрат может являться родителем для прямоугольника в том случае, если мы исходим от кол-ва свойств. Для описания квадрата достаточно одного свойства — «длина стороны a». Легко высчитываем его площадь, геометрию и прочее. Прямоугольник, унаследованный от квадрата, приобретает ещё и свойство «длина стороны b».
        Четырёхугольник или многоугольник уже не очень вписывается в эту цепочку, потому, что у них нет свойства «длина стороны a/b», а есть количество точек и массив этих точек. Но опять же, подобное рассуждение ни к каким конкретным выводам меня не привело.
      • UFO just landed and posted this here
          0
          Очень плохо. Инструмент надо свой знать. Зачем докладчик взял инструмент в котором не разбирается. Если пишите на PHP приводите пример на PHP. В PHP есть интерфейсы и Вы не допустили бы такое количество ситуаций на докладе: статическое(классовый атрибут) объявление атрибута, заминка с метаклассами. Одним словом идея и желание у Вас отличное, но вот зачем выбрали неизвестный язык совершенно с другой философией непонятно. Опять таки если хотелось показать какие-то инструменты ну взяли бы Java с ее Spring и показали на реальном контейнере IoC.
            0
            Второй доклад, а по операциям у меня вопрос нельзя ли взглянуть на исходный код тестов. Так как что-то мне подсказывает, что 3 ** 30 будет оптимизирован на этапе создания байт кода, а вот pow(3, 30) сделает честные вычисления. Предпринимали ли Вы какие-то попытки для отключения оптимизации? Почему Вы используете IPython, а не классический CPython разработанного Гвидо?
              +1
              IPython — просто CLI-оболочка, под ним может хоть CPython быть (чаще всего), хоть PyPy, хоть Jython.

            Only users with full accounts can post comments. Log in, please.