Пользователь
0,0
рейтинг
29 марта 2012 в 01:19

Разработка → Ответ на Python vs Ruby

Пользователь eyeofhell недавно написал статью Python vs Ruby.
Знатный холивар получился. Не могу не поддержать. Сначала думал написать в комментарии — но ответ вышел слишком объемным.


О себе:
Я пишу на Питоне десять с лишним лет, с Руби знаком довольно поверхностно.
С недавних пор являюсь Python Core Developer с commit rights.

На последнем US PyCon в Санта-Кларе Гвидо ван Россум произнес замечательную речь — всем рекомендую посмотреть.

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

Теперь по конкретным претензиям к автору (по части Питона, конечно — пусть знающий рубист тоже скажет веское слово).

— Питон имеет встроенный модуль ssl. Из-за древних лицензионных дрязг с Микрософт (поправьте, если не так) в дистрибутив для Windows этот модуль не включается. На всех остальных ОС он есть.

— subprocess позволяет указывать параметры командной строки одной строчкой, при этом следует вызывать с параметром shell=True. Это не так лаконично, как просто скобки — но способ есть. К тому же следует понимать, что вызов подпроцесса далеко не всегда сводится к подстановке текстового вывода в переменную. Есть еще return code, stderr, интерактивность…

— Питон может импортировать модули по относительному пути. Это именно относительный путь для модулей, а не файлов. Модули должны лежать в пакетах (папках, в которых есть __init__.py). Читатели уже указали на этот момент.

— codecs.open позволяет указать кодировку для открываемого файла. open поддерживает параметр encoding для тех же целей.

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

Прочее: как уже читатели отметили, некоторые части не включены в дистрибутив Питона, но доступны как сторонние библиотеки.

— pytz. Список timezone обновляется чаще, чем полуторагодичный период для выпуска нового Питона. В документации ссылки на pytz нет — поправим.

— шаблонизатор. Большее, чем string.Template в стандартную поставку не включили. Потому что не ясно, какой шаблонизатор устроил бы всех. jinja2, которым я пользуюсь — отличная штука. Опять же слишком быстро развивающаяся и слишком независимая, чтобы быть частью Питона как дистрибутива.

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

И, наконец, главное.
python2 уже мертв. Да, мы часто делаем bug-fixes. python2.7.3 будет скоро. Но Двойка закончилась два года назад.

Все больше и больше библиотек подтверждают свою поддержку Тройки.
— SQLAlchemy сделала это уже давно.
— Jinga2 — тоже.
— Pyramid — неделю назад.
— WebOb, от которого зависела Pyramid — в конце прошлого года.
— Django тоже перейдет на тройку — они обещали.

Ребята, Python3 — это ваше будущее, которое наступает на пятки. Будьте готовы!

UPD: Django 1.5, которая выйдет осенью, будет иметь экспериментальную поддержку Python 3.3
Андрей Светлов @svetlov
карма
81,2
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (147)

  • +18
    Пишу на Питоне 6 лет, раз в год пытаюсь перейти на 3, и все никак не получается. Двойка форева.
    • 0
      Можете рассказать, почему все еще никак?
      • НЛО прилетело и опубликовало эту надпись здесь
        • +7
          Так-так. Уже давно пора бы переехать с 4-5 дебиана на 6й. Это совсем не дело!
          • +1
            Да и 6-й Debian тоже уже старый как дерьмо мамонта, так что лучше testing ветку юзать, благо она достаточно стабильна и контроллируема.
            • +1
              Да зря минусуете. Парень, конечно, на язык не разборчив, но он прав. testing вполне очень даже пригодна использования. И многими используется, в том числе и для production.
              • 0
                Заметте, на свой страх и риск.
                • 0
                  Да, когда дело не касается Debian, в котором свой взгляд на testing. Если немножко поутрировать, то можно перевести так:

                  — Debian-testing — рабочая версия,
                  — Debian-stable — «вылизанная», но не очень свежая версия.

                  По поводу сравнений Debian-testing и stable других дистрибутивов (Ubuntu и т.д.) — много писалось, вот некоторые ссылки:

                  www.linux.org.ru/forum/talks/5086977
                  habrahabr.ru/qa/8038/
                  citkit.ru/articles/456/
        • +6
          ладно еще 5(хотя тоже ахтунг), но… 4?!?!
          жесть ребята, жесть.
        • +1
          просто подходишь к админам и говоришь, что нужен Python X.Y. Я собрал специально Python 2.6/2.7, PyPy для CentOS 5/6 и положил в локальный репозиторий. Все отлично работает. Для CentOS достаточно пересобрать сам пайтон и setuptools.
        • +1
          > в которых просто нет python3.

          — Ребят, ну ей Богу..., ну лучше бы не говорили… Из исходников Питон ставится за 5 минут..., тем более на Дебиан. Ну никак это не может быть «серьезной» причиной…
          • 0
            Коль я уже заикнулся, то, наверное, будет уместно упомянуть коллекцию Питонов github.com/collective/buildout.python устанавливаемых через buildout.
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Стабилен был всегда. После версии 3.1 появился мораторий на изменение синтаксиса. Действует до сих пор (добавился только yield from, принципиальное согласие на который было получено еще до выпуска 3.1).
      • +2
        А есть какие-нибудь интересные материалы на тему, почему стоит переходить сейчас? я помню на вторую версию тоже перешел не быстро, правда, уже не помню почему.
        • 0
          Вот как раз первого апреля на kiyv.py буду об этом рассказывать.
          • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            Почему, почему я об этом узнал только 31го марта ??
            ааааа!
      • 0
        Меня удерживает Werkzeug, который, AFAIK, никак не может перейти на Тройку. Очень не хочется с него уходить. Если он навечно застрянет в прошлом, тогда другой вопрос.
        • 0
          не понятно, в чём проблема — в тройке есть и юникодные, и бинарные строки.
          • 0
            Почитайте блог Армина Ронахера, он очень подробно рассматривает эти вопросы.
            • 0
              мм… что конкретно? на данный момент есть pep-3333, описывающий инженерное решение заморочек для python3. т.е., если не впадать в научный креативизм (имею ввиду pep-0444 от Армина), можно сделать всё уже прямо сейчас.

              • +1
                Я уже не помню, надо будет перечитать и блог, и PEPs. В любом случае, если WebOb поддерживает оба питона, явно как-то можно и WZ перенести; кроме того, где-то валяется дохлый форк WZ, который, вроде бы, уже решал задачу (не знаю, почему так и не был втянут в транк).
      • 0
        Потому что PyPy пока не того. А производительности хочется сейчас.

        Но как только PyPy подтянется, то и смысла нет.

        Ах да, еще хочется гринлетов в PyPy с JIT.
        • 0
          Очень абстрактные хотелки. Практически всегда можно выжать достаточную производительность и с CPython.
  • +4
    Думаю слухи о смерти python2 несколько преувеличены. И проблема, наверное, не столько в библиотеках даже, сколько в том, какую максимальную версию можно ожидать в произвольной популярной ОС/дистрибутиве без лишних телодвижений. Грубо говоря, какие возможности python должен использовать скрипт, чтобы его можно было скопипастить и он заработал на большинстве машин, где какой-то python есть.
    • +1
      Оооо. 1.5 наверное всех устроит.
      • 0
        У меня сейчас на десктопе (специально не ставил) Python 2.7.3rc2, на сервере — 2.6.6, в GAE (c недавних пор) — 2.7 можно использовать, а не так давно 2.5 максимум. Угадайте, буду ли я использовать python3 (да хотя бы 2.7) фичи в своих скриптах? И использовал ли я 2.6 фичи ещё не так давно?
        • +2
          Я жду осеннего релиза Django с частичной поддержкой Python 3.3.
          Сам все это время буду сидеть на альфе джанги и далее и рапортовать баги и помогать пилить ее для тройки.
          У меня сейчас 2.6.7, 2.7.3rc2 и 3.2.3rc2. Сам тоже ничего не ставил специально.
          • 0
            Какой дистр 3.2.3 включает, если не секрет?
            • 0
              Я ниже писал что у меня ubuntu 12.04 но питон 3.2 установился кажется как зависимость чему-то. Не помню стоял он уже или нет. В 11.10 тоже он установлен был.
              • 0
                У меня тоже 12.04, но только что поставил python3 ручками. Причём делал апгрейд дистра, а не чистую установку.
            • –1
              я на archlinux уже лет 5, там всегда последние пакеты, python 3.2 там уже есть давно :)
          • 0
            на production-серверах?
        • 0
          У меня на ноуте («Мак») — python 2.7.1. Третьего «из коробки» нет.
      • 0
        Всех пока устроит 2 :) Много систем в продакшене на RHEL5 и производных — питон 2.4, а новый RHEL6 перешел только на 2.6.
        А учитывая десятилетний lifecycle этих систем — Python 2.x еще долго будет жить.
        Не стоит забывать и про Solaris. в 10й версии только 2.4 в поставке, для Solaris 11 доступны 2.4/2.5/2.6…
        Т.е. как бы не хотелю люди начать использовать версию 3.x — все упирается в отсутствие этой версии в продакшене.

        ЗЫ. На десктопе стоит и 2.х и 3.х версии, но сколько бы не пробовал новую версию все равно вынуждет следовать версии 2.4, так как продакшн.
    • 0
      Тут надо отличать софт, написанный на Питоне, от копипащенного скрипта. Если человек копипастит скрипты — он если не программер, то по крайней мере продвинутый юзер, и поставить тройку сможет без проблем. Если это домохозяйка, ставящая новую софтину, то о зависимостях в любом случае должен заботиться установщик (будь то пакетный менеджер или отдельный инсталлер). А иначе имеем замкнутый круг: софт не пишем, потому что в системе только старая версия, а система не обновляется, потому что ей это не надо — все и так работает.
      • 0
        Я не рискую ставить тройку — боюсь, что софт и скрипты, зависящие от двойки, перестанут работать — были проблемы с другими языками, которые меняли симлинк /usr/bin/ на другой. Свои-то (и даже чужие скопипащенные) скрипты я и проверю, и перепишу если надо. Но вот даже получить список пакетов своих (используемых мною) дистров, которые зависят от python, мне что-то совсем не хочется, не говоря об их тестировании хотя бы на уровне «запустится или нет».

        И поправьте меня если ошибаюсь — пакетные менеджеры питона разруливают зависимости только между модулями питона.
        • +2
          Проверил, после установки тройки python остается 2.7.2.

          Пакетные менеджеры — я имел в виду системные. Домохозяйке pip точно до лампочки.

          Мне кажется, что они весьма круто поступили, забив, с одной стороны на обратную совместимость, а с другой — сделав в двойке (пусть и только в достаточно свежей 2.7) возможность писать код, работающий и на 2.7, и на 3.

          И да, у меня тоже есть сервер с 2.4, но там и все остальное — такое древнее дерьмо мамонта, что что-то туда серьезно дописывать смысла нет.
          • 0
            Спасибо. Рискнул поставить 3.2 — да python --version пишет 2.7.3rc2. Теперь буду налегать на 3.2 фичи при скриптовании.
        • +1
          Не бойся все окей. у меня уже давно дивут 2.6/2.7/3.2 никаких проблем.
          состема сама выставила питон по умолчанию и проги не конфликтуют.
          а виртуальные окружения создаю с любой нужной версией питона или pypy.
          У меня ubuntu 12.04 x64 если что.
          • +3
            состема дивут!!)
          • 0
            С виртуальными окружениями не разбирался — для самописных скриптов, которые пишу на python (из-за лени разбираться с bash, наверное, плюс подозрения, что DDD на нём реализуется не совсем очевидно), имхо, оверхид (судя по ruby с rvm).
  • –4
    у руби и питона есть одно ОГРОМНОЕ отличие которое собственно и определяет его приверженцев и имя ему — синтаксис.
    • +16
      Ничего не понимаю. Слово «Синтаксис» должно вызывать экстаз?
      • 0
        Не думайте что я отвечаю только вам, просто комментарий ваш самй первый и удобнее писать тут.

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

        Синтаксис это всетаки большая часть языка программирования (вообще вам слово «язык» в этом наборе ничего не говорит?). В руби он всетаки гораздо гибче, а в остальном языки одинаковые по своей идеологии и функционалу. Выбирай, как говорится, фломастеры на свой личный вкус :)

        P.S. примеров syntax sugar ruby в инете вагоносоставы, поэтому приводить не буду, но является это ключевым моментом для выберающего ЯЗЫК программирования при прочих равных или нет, решать выбирающему.
        • +1
          Конечно же всё упирается в философию: идеология Python явно говорит о том, что должен быть только один путь достижения цели, тогда как Ruby напротив говорит о том, что должно быть несколько путей. Каждый выбирает то, что ему ближе, но все ведь понимают, что именно подход Python позволяет получить более поддерживаемый и чистый код в условиях современной коммерческой разработки.

          Без «навязывания» определённого стиля никуда, если это не делается на уровне языка, то это делается путём различных coding style conventions/recommendations (ключевое слово «различных»). Часто «меньше» на практике выливается в «больше». И если индивидуальный разработчик может выбирать, то при работе в большой команде приходится задвинуть личные предпочтения подальше.
          • 0
            Всё зависит от уровней разработчиков в комманде. Если в команде скил прыгает семимильными шагами от разработчика к разработчику, то без введение codestyle никуда. И как правило этот стиль навязывается более старыми (увы не всегда более квалифицированными) разработчиками.

            Если же команда состоит целиком из специалистов высокой квалификации то разницу в размещении фигурных скобок и именовании переменных никто не замечает.

            С годами вырабатывается привычка и DRY-ить и KISS-ить и постоянный рефакторинг (не кода ради а структурной простоты для) и короткие функции. Лично я бы навязывал именно эти практики, а не личные предпочтения одного человека, который навязал всем свой кодстайл.
            • +12
              А у нас просто PEP-8…
    • 0
      Если синтаксис — это основной критерий, на который вы опираетесь при выборе языка, то у меня для вас плохие новости.
      • –1
        при выборе между питоном и руби разницы большой нет, кроме синтаксиса :) так что тут все логично.
        • +8
          Гкхм, [i]/me трижды поперхнулся[/i]

          Ну ок, а семантика, объектная модель, особенности рантаймов никому не нужны видимо.
          • +7
            Для большинства задач (по количеству) это нюансы, которые зачастую даже учитывать не нужно.
            • +4
              Что? Это не нюансы, это основные характеристики любого ЯП! Может еще и типизацию в нюансы записать, а разделять языки по наличию semicolon'ов в конце выражений?
              • +5
                Для круга задач, где динамическая типизация не требуется (опять-таки, имхо, подавляющее большинство), — почему нет? Стоит задача, утрируя, написать «Hello world» для единственного пользователя, которому всё равно будет программа работать 1 мкс или 100 мс. Вы будете думать при выборе ЯП об особенностях рантаймов Python, Ruby, PHP, C++, С#, VB, Delphi, Java или JavaScript (вроде все популярные ООП языки перечислил)?

                Я к чему: для большинства задач (простого количественного большинства, без учёта «веса» по сложности, нагрузки, критичности, стоимости ошибки, количеству инсталляций и т. п.) выбор языка (в рамках одной парадигмы и сравнимом количестве и качестве библиотек/фреймворков) — это вопрос вкуса, знаний, опыта и прочих фаз луны, если отбросить такие экономические параметры как популярность, рейты разработчиков, стабильность и прочее, собственно к реализации решения задачи на уровне «работает/не работает» относящееся мало.
                • –2
                  Вы знаете, я вот сейчас прокрутил в голове Пайтон, Гоу и Хаскель и не согласен с вами совершенно.
                • +1
                  Фёрстворлдпроблемс, на чем написать хэллоу ворлд…

                  > Я к чему: для большинства задач (простого количественного большинства, без учёта «веса» по сложности, нагрузки, критичности, стоимости ошибки, количеству инсталляций и т. п.) выбор языка

                  У сильное ощущение, что это субъективное большинство задач — сделать сайт-визитку или лабораторная в институте, но и там и там есть предпочтительные вещи.

                  > вопрос вкуса, знаний, опыта и прочих фаз луны, если отбросить такие экономические параметры как популярность, рейты разработчиков, стабильность и прочее

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

                  Поэтому давайте дружно брать и писать на BF. Тьюринг-полнота аллилуйа!
      • +14
        Ну, кстати, синтаксис это действительно весомый аргумент при выборе — хотите вы этого или нет. Подобно тому, как при выборе авто весомую (а иногда и определяющую) роль играет его дизайн.
        Синтаксис это то, с чем имеешь дело постоянно и ежеминутно. То что держишь «на кончиках пальцев» и оно не должно раздражать. Легло на душу или не легло.

        Опять же, порог вхождения сильно влияет на распределение рынка. Почему такого бешеного успеха добился jQuery? Он настолько лучше всех аналогов? Сомнительно.
        Но он предельно понятный — во всяком случае, базовые возможности. Человек, поверхностно знающий JS, открывает несколько примеров и — о чудо! — без подсказок понимает, что там происходит.

        Сам я не пишу, ни на Питоне, ни на Руби. И вообще верстальщик :) Поэтому я условно-нейтральная сторона. Чисто субъективно, Питон мне кажется понятнее и как-то… естественнее.
        • 0
          Питон развращает.
          Теперь смотреть на C php и другие языки противно. Потому что слишком много избыточности.
          Зачем эти скобки, точки с запятыми? Эти заявления типов и т.п. и т.д.
          jquery спасает в яваскрипте похожей простотой.
          Вот и все.
        • –3
          Руби всё же более логичный и продуманный. Нет странных синтаксисов с квадратными скобками или там с кверхногамизаписанными join-ами :)
          • +2
            Можно примеры странных и кверхногами конструкций? А то мне сложно судить, не сталкивался.
            • 0
              ",".join([str(i**2) for i in range(10)])

              join как метод строки поначалу непривычно, а в остальном — ничего странного.
              • 0
                В данном случае квадратные скобки можно смело выбросить.
      • 0
        Данные языки решают одни и те же вопросы, иногда разными тропинками, поэтому выбор остается, скажем так, за стилем программирования — будет более правильно.
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            Есть очень схожие подходы к решению этих вопросов. Есть основные направления и есть множество тропинок в основном вдоль основных направлений, хотя и есть тропинки (даже довольно утоптанные) идущие «своим путём».
  • +1
    Спасибо. Про codecs.open — действительно, запамятовал :(. Убрал этот пункт.

    По поводу OpenSSL — вы скорее всего путаете OpenSSL как библиотеку и SSL как протокол соединения поверх TCP. SSL действительно есть и ставится ActiveState. OpenSSL штатного нету, нужно ставить поделки вида M2Crypto или pyopenssl. Вот недалее как вчера в M2Crypto багу нашел вида «ничего не работает».

    По поводу subprocess и shell — я уже писал, это не работает ни в каких комбинациях если мы под windows и пробелы случились одновременно в пути к программе и в одном из аргументов. Смиритесь — в system() из CRT это тоже не работает. А в Ruby — работает.

    Импорт по относительному пути — это когда у нас есть PATH в котором ищем common и оттуда грузим. Питон так не может. То что он может импортировать специальным образом оформленную подпапку — это не совсем то.

    По поводу потоков — это даже Qt может, который вообще C++. Ничего сложного если «главный цикл» в потоке крутим мы сами. Для ресурсов есть деструкторы / счетчики ссылок.

    Ну а про сторонние библиотеки тоже соглашусь, но я сразу написал что если их сравнивать — то статья лопнет как та корова. Да и компетенции мне не хватит.
    • НЛО прилетело и опубликовало эту надпись здесь
      • НЛО прилетело и опубликовало эту надпись здесь
        • +1
          Есть прекрасный пост на эту тему Как устроен GIL в Python
          • 0
            Я тоже прошлым летом довольно подробно расписывал, как именно работает GIL и как он не работает, что бы кто не думал: asvetlov.blogspot.com/2011/07/gil.html
        • +2
          Не правы, питновские потоки — это «настоящие» потоки, они не выполняются в одном системном потоке.
    • 0
      Если вам важен именно OpenSSL — то да, его нет. Мне показалось, что речь шла именно об отсутствии поддержки ssl Питоном. Извиняюсь, вышло недопонимание.

      Пробелы и shell. Я не увидел слово «Windows». На posix пробелы обрабатываются корректно.

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

      А вот по поводу потоков совсем не соглашусь.
      — Главный цикл в потоке мы сами крутим далеко не всегда. Более того, не всегда главный цикл в потоке вообще есть. Как всё ещё нет и определения/стандарта для главного цикла если он всё же присутствует. У Qt свой главный цикл, а у twisted или tornado — свой…
      — Если поток подвис на выполнении кода C Extension — его можно прибить (pthread_kill/TerminateThread). Но освободить ресурсы не получится. Не все ресурсы зарегистрированы в Питоне — некоторые могут принадлежать С Extension. Создавать объект в одном потоке, а деструкторы иногда запускать в другом — не самый чистый дизайн. Не весь код покорно снесет подобное издевательство.
      — Если же у нас есть свой главный цикл потока, который работает устойчиво и не блокируется надолго — нет никаких сложностей в явной отсылке сигнала этому циклу с просьбой завершиться. Во всех прочих случаях проблема не решается в общем виде.
      • 0
        Да, у меня на posix тоже все работало. А потом когда развернул в production на несколько сотен — начался подземный стук. Сначало локализовалось что это Windows. Потом пробелы. Ну и наконец — пробелы в имени программы и одного из ее аргументов. Токая неконсистентность довольно болезнена для кроссплатформенной разработки :(.

        На мой профессиональный взгляд, преимущество относительного импорта не в том что там импортится — файлы/модули/whatever, а в том, что для сложной программы мы можем вынести некий модуль/часть программы в папку «common» и импортить ее из вложенных папок — даже из тех, которые находятся «ниже» папки common в иерархии файловой системы. Ruby это позволяет сделать в одну команду, питон — в много команд со спецэффектами. Это различие, я его подчеркнул. И да, я знаю много способов организации исходных кодов и разделения программ на компоненты — в ряде случаев, действительно, за глаза хватает функциональности питона. Но не всегда ©.

        — Главный цикл в потоке мы сами крутим далеко не всегда. Более того, не всегда главный цикл в потоке вообще есть. Как всё ещё нет и определения/стандарта для главного цикла если он всё же присутствует. У Qt свой главный цикл, а у twisted или tornado — свой…


        Питон — язык, работающий поверх виртуальной машины. Поэтому код питона, который выполняется в потоке всегда можно остановить, не нарушая физической целостности программы. Безусловно, если все что делает поток — это вызывает внешнюю функцию через FFI, то остановить его средствами языка действительно логически затруднительно. Но в общем случае, если в потоке выполняется код питона — числодробилка, или пинг в цикле — то остановка такого потока средствами языка — вполне себе штатная операция. Для небольших, но многопоточных утилит такая возможность на уровне стандартной библиотеки — это, на мой взгляд, достаточно большой плюс, чтобы я его вынес в сравнение :)
        • 0
          Пробелы и subprocess: создайте баг в bugs.python.org
          Будет совсем здорово, если он будет с тестом и патчем. Это же OpenSource!

          Импорты — давайте замнем для ясности.

          Потоки. Еще раз: вы приводите частные случаи, где остановка потока полезна и безопасна. Но существует слишком много вариантов, которые не вписываются в предложенную схему. Поэтому Питон и не имеет стандартной возможности принудительного завершения потока.
          • 0
            Попытки оградить программиста от «потенциально опасных» вещей — это, безусловно, хорошо. Но снижает лаконичность и гибкость языка. Проблема сложности, complexity problem — зверек не белый и пушистый. Подкрадывается незаметно, откусывает сразу голову. Все мы помним чем закончилась попытка сделать «безопасный для программиста» язык, Java. И какие к нему основные претензии.
            • +1
              После нашей переписки и обсуждения вопроса с коллегами я пересмотрел свою позицию.

              Возможно, вам будет интересно посмотреть на дискуссию, которую я поднял на python-ideas в теме Thread stopping. Голосуйте за предложение, что ли…
              • 0
                Спасибо. Рад, что моя позиция достаточно разумна, чтобы привлекать сторонников естественным образом. Попробую добавить в копилку и свой голос :)
              • 0
                BTW, я думаю stop() было бы более идеоматично, нежели interrupt. Во-первых, это во всех остальных языках называется stop. Во-вторых, interrupt подразумевает resume, а остановка потока, насколько я понимаю, подразумевает что он после этого останавливается.
  • +1
    Кстати pypy пока тройку еще не поддерживают. А так мы конечно все на тройку согласны.
    • 0
      Deepwalker, специально для тебя.
      Гвидо спросил: Кто использует pypy в production? Несколько рук. Кто использует cpython? 2000+
      И кому интерессна эта pypy? Замечательный проект, к слову.
      • +2
        «Интересен» и «Использует в продакшн» — это два разных понятия: многим интересен pypy (ведь они смотрят на впечатляющие графики), но его ещё очень не скоро рискнут использовать в продакшне.
        И раз уж вы Python Core Developer, подскажите пожалуйста, почему в datetime.timedelta нет такой очевидной вещи, как months (и years), приходится ради такой мелочи либо ставить стороннюю библиотеку, либо писать велосипед.
        • +1
          Кстати, этот сайт использует pypy seatgeek.com/
          • 0
            pypy вполне хорош в продакшне.
            Использовал его с pymongo которая поддерживается в pypy.
            А деплоиться можно например nginx + uwsgi(c плагином pypy) — django
            • 0
              Я именно о массовом использовании — его пока побаиваются…
              • 0
                Ну да. побаиваются) pypy еще пилить и пилить… И использовать можно только там где знаешь что поддерживается и что знаешь что так будет лучше. А иначе какой смысл если за слоями кешеров все будет одинаково.
          • 0
            Из больших сайтов, использующих PyPy, стоит упомянуть Quora.
        • +2
          не думаю, что это не так уж и очевидно, но имхо дело в том, что в months и years — это не константные величины, то есть, в месяцах и годах вполне может быть разное кол-во дней, вы хотите чтобы питон сам высчитывал?:) и как? timedelta(months=1) прибавлять 28/29/30/31 день месяца? или вы хотите просто менять циферку месяца?
          • 0
            Да, конечно понятно, что речь идет не об абсолютной, а относительной дельте. Речь идёт именно о смене цифры месяца (но с учетом количества дней в итоговом месяце). Почему не очевидно, разработчикам сторонних библиотек очевидно же…
            • 0
              пятый час, перемудрил, хотел сказать, что это достаточно очевидно. На самом деле, я модулем datetime пользуюсь чаще всего, я бы даже сказал, что каждый день и уже очень давно. Я такой проблемы не испытываю, сталкивался один или два раза, по-моему, с такой задачей. Думаю, что это как раз дело какого-нибудь стороннего модуля.
            • 0
              timedelta — это просто ещё один вариант записи относительной даты, не меняющий арифметических свойств (коммутативность, например). Для года и месяца это нарушается, поэтому в библиотеке специально и не реализовано.

              Типичный пример:
              29.jan.2011 + 1 year + 1 month = 29.feb.2012
              а теперь наоборот
              29.jan.2011 + 1 month + 1 year = 28.feb.2012
        • +1
          > почему в datetime.timedelta нет такой очевидной вещи как months (и years)

          Потому, что в общем случае она для _интервалов_ времени невозможна.
  • +9
    Вобщем как говорят некоторые программисты(которые знают и руби и питон): если выбираешь между руби и питоном то ты точно не ошибешься. Холиварить можно до усрачки хоть каждый день и никчему не прийти.
    Лично мне нравится питон. На нем я могу быстро написать хоть сайт, хоть прогу с гуевиной(или без) или приложение для iPhone да и добрая половина моей родимой бубунты написана на питоне и я могу все менять итд. Почему не на руби а на питоне? почему питон стоит в каждом почти линуксе и маке а руби нет?

    В конце концов язык программирования это язык на котором мы говорим с машиной. И мы выбираем тот язык на котором нам приятнее и удобнее говорить, кто-то малословный и любит коротко и ясно… кто-то любит поболтать — пожалуйста другой язык. кто-то любит разжевать все до мелочей — третий. итд… под каждую задачу своя интонация и язык… Ну я утрирую канешно)) не кидайтесь камнями.
    • +3
      В маках руби стоит из коробки как минимум с версии 10.4. Подозреваю что во всех предыдущих тоже стояло, но тут не уверен.
  • +4
    Да и есть же стереотипы, которые доносят евангелисты, есть экосистема и приоритетные фреймворки. Первые мои ассоциации с Ruby: культовый Rails, аура Apple и Mac OS, трендовый GitHub, стартапы — всё это сильно действует на «хипстерское» сознание. Python гораздо более академичен, шире применяется, настоящий и полноценный мейнстрим не только для веба. Пусть и не отражающие возможности языка, эти представления всё равно в конечном счёте следуют из особенностей, преимуществ и сообществ вокруг этих двух замечательных языков. Это как сравнивать iPhone и Android без маркетинга. Где искать различия в интерфейсе, в доступном API, внешнем виде и доступных приложениях можно до бесконечности.
    • –7
      за хипстерским сознанием кроются мощные технологические скиллзы а вся эта напыщенная академичность вызывает рвоту.
      • +2
        как же хорошо, что не все рубисты такие тролли
      • +1
        Не твои ли слова служили мотивом к тем нашумевшим действиям по показу уязвимости рельс на гитхабе, слова о том, что большая часть тех, кто пишет на ruby on rails в основном люди с поверхностными знаниями? :)
        А так согласен — везде есть свои хакеры и свои ботаны. Но твой стереотип понятен, это как раз то о чем я и говорил.
        • –1
          стереотип? нет. просто мне не нравится «академичность» и ботанизм, надо больше фана. остальное тут не причем
          • +2
            твоя правда, но фан, кураж и адреналин можно найти везде
  • 0
    В частности, он указал что Питон и Руби — почти что близнецы-братья.


    Если я правильно помню, то Гвидо в своей речи разделил языки по проблемным областям и уровням абстракций, при этом вышло, что python-ruby-perl образуют суть один пласт. С такой его трактовкой сложно не согласиться. А вот про близнецов не вспомню.
    • +1
      Python, and Ruby, and Perl are exactly the same language.

      www.youtube.com/watch?feature=player_detailpage&v=EBRMq2Ioxsc#t=351s

      И там не про проблемные области и абстракции, а про принципы устройства языка и его коммунити. На ту же полочку он положил и Lisp.
      • 0
        Только не кастрируйте цитату, ведь в оригинале она не просто так начинается с ремарки про 10 км.
        Вот эти 10 км — абстракция, позволяющая судить об уровне сходства/различия языков. И, таки да, сообщества — дополнительный частный пример сходности. Опять же, если не забывать про 10 км.

        Из контекста можно судить, что речь идёт, как раз о разделении языков по областям и уровням.
        К сожалению не могу прокомментировать замечание про «принципы устройства языка», т.к. не понимаю что вы имеете ввиду под этим словосочетанием %)

        Поднимитесь на 50 км, и вы увидите, что все языки программирования сходны, с сотни км можно будет говорить об одинаковости любых языков и о том, что все люди братья.
        • +2
          А 10 км это много или мало с точки зрения Гвидо? ;) Может быть это как раз высота достаточная для того чтобы абстагироваться от синтаксиса, некоторых нюансов и особенностей устройства ООП.

          Ну ок, динамическая типизация, ключевое свойство языка. Исходя из этой характеристики строится весь язык, начиная с низов, заканчивая самыми высокими абстракциями. Поэтому clojure куда ближе к руби / питону, хоть и функциональная, чем Scala, которая, вроде как, куда больше похожа на обычные программы на руби и питоне.

          Если говорить о моем личном мнении, то я вижу достаточно различий между руби и питоном, как в языках, так и в коммунити, что бы отдать предпочтение одному из них, не скажу какому. А цитату привел, потому что фраза «Питон и Руби — почти что близнецы-братья», все же не так уж далека от того, что сказал Гвидо ;)
  • +2
    > уничтожить поток.… Поэтому Питон и не имеет такой возможности.

    Я считаю, что реализовать функцию (в ядре питона) уничтожения потока не тяжело, её специально не делают — как бы подталкивают к правильной разработке программ. Т.е. это скорее является «фичей» чем «минусом».
    • 0
      Уничтожить поток — легко. Правильно освободить ресурсы — невозможно в общем случае.
  • +2
    ждем ответ на ответ от рубиста
    • 0
      на что отвечать? тут какие то абстрактные оправдания, наезда на руби не видно.
      есть несколько знакомых, которые раньше писали на питоне а сейчас предпочитают руби, потому что на нем приятнее.
      • 0
        просто закономерность, необходимости в этом ответе (этой статье) я так же не увидел
  • 0
    Вы уж как-нибудь отпинайте там Django, чтобы она не «обещала», а делала. Потому что тройку хочется, но что толку если в моем случае там нельзя сделать добрые 2/3 того, что в двойке.
    • 0
      В этом году уже будет экспериментальная поддержка Python 3.3
      • –6
        вау. в этом году. так медленно разрабатывать надо уметь.
    • +1
      Полуофициальный форк с поддержкой 3го питона ( bitbucket.org/vinay.sajip/django ) давно есть, он регулярно мерджится с апстримом и его скоро влить должны в транк. Лучше не пинать, а помогать — ставьте его, пробуйте, исправляйте, что не работает. Кого пинать-то? Над джангой точно такие же люди работают, по своей инициативе, никто им за это ничего не платит, за что их пинать-то.
  • +2
    Не вижу смысла в этом довольно старом споре, большинство делает выбор решающим фактором которого становится синтаксис, а потом все остальное.
    Сама тема аналогична убеждению кого-либо в сексуальном предпочтении, кому-то нравятся девочки, кому-то мальчики, если человек имеет твердое убеждение, то никакие факты не помогут. Тоже и касается вопроса выбора Python vs RuBy.
  • –1
    Андрей!
    А можешь выступить с этим анализом на секции DevConf::Ruby?
    devconf.ru/offers/ruby

    А рубисты сделали бы ответный алаверды на питонячей секции?
    • +5
      А кто потом будет разнимать?
      • –2
        да… потасовка
    • +5
      Да какой же это анализ? И что мне делать у Рубистов?
      Давайте я вам лучше расскажу, чем Python3 лучше Python2. Тоже наваристый холивар для тех, кто понимает.
      • 0
        Андрей, лучше расскажите про SSL и subprocess. А то как-то неудобно получается — написали громкое опровержение, написали что я не знаю матчасть — а после того, как я внимательно все изучил и задал уточняющие вопросы — тишина, спокойствие. Мне же тоже интересно — может, действительно subprocess работает, SSL и OpenSSL — одно и тоже, а Qt останавливает потоки волшебным образом? :)
      • 0
        Андрей, да! Мне кажется сейчас самое время для такого рассказа.
        • 0
          На Kyiv.py будет пробный прогон через 3 дня :)
          • 0
            Запись выложите ) Жаль на kharkivpy не получилось нормального видеомоста, не доработали мы с Егором этот момент.
            • 0
              Не уверен, что запись вообще будет. Вроде бы никогда не писали.
  • 0
    По моему опыту в переходе Py2 на Py3 самая большая проблема это юникод (за ногу его) — В Py2 — str это bytes в Py3 — и это делает много… нет МНОООГО геморроя.

    Вот сейчас буквально копаю
    В freeswitch библиотека эвентов интерфейсится на Питон используя генератор SWIG. В генерированной либе при поступленнии эвента Exception возникает в c++ коде — который пытается отдавать мне (если я юзаю Py3) — PyUnicode вместо PyString для Py2. — ручками я добрался и заменил его на PyBytes — Но ребята (коре питоновцы) — строки — это то что мы все используем и такие изменения нужно делать както по-другому, чтобы это не ломало все и вся. (я не про SWIG а про изменение str — bytes)
    И такие примеры с юникодом на каждом шагу и в куда более простых применениях.
  • 0
    Мысли о Python3 от автора Jinja2 — http://lucumr.pocoo.org/2011/12/7/thoughts-on-python3/
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Дизайн его блогов и докладов многим нравится. Есть тема оформления для sphinx, которую сейчас ставят все подряд.
        Но в общем дизайн это же так. Что мне нравится гораздо больше в Армине, это что за написанием кода, хорошего на мой вкус, хоть и не все его идеи удачны, он не забывает писать прекрасную документацию, ясно и доступно выражая свои мысли. Я вот пока так не могу. Донести до хабра прелести trafaret я так и не смог, по всей видимости.
  • 0
    Интересно было бы услышать мнение человека солюшен архитектора. Когда при старте проекта следует выбирать руби, а когда пайтон.
    • 0
      Можно без архитектора — надо писать на том языке, который лучше знают имеющиеся разработчики.
      • 0
        Угу
      • 0
        Представим, что есть и такие, и такие. При старте проекта еще на этапе обработки RFX, когда стоит советовать Python?
        • 0
          Очень похоже на: «Когда при разработке следует выбирать VIM, а когда — emacs?»
  • –10
    Ruby is full of love.
    Python isn't.
    • +5
      Full of love and unicorns. Единороги — это очень важно. Без них ничего не работает, особенно потоки O_O.
  • 0
    попробовал поставить под python 3 пакеты проекта, половина пакетов пока не собирается :(
    впрочем я не особо тщательно пытался, возможно с бубном получится их завести.
    и возможно помогу с переводом каких-нибудь на python 3 если руки дойдут.
    а так очень ждем эти:
    Flask, Werkzeug, Pillow, WTForms, webassets, redis, hiredis, gunicorn, pytils, gevent, ujson, raven, bleach.
    • 0
      Поддержку 3го питона мы в pytils на www.ekbpy.ru/ добавили ( github.com/kmike/pytils ), но там потом репозитории немного разошлись, смерджить руки ни у кого не дошли. Форк должен работать под питонами с 2.6 по 3.2.
      • 0
        хорошо, поставлю оттуда :)
    • 0
      WTForms и hiredis используем без проблем.
      gunicorn будет — на PyCon David Beazley публично застыдил Benoit Chesneau и последний пообещал таки портировать.
      • 0
        о, здорово, попробую повозиться и завести их :)
        ждем gunicorn :)
      • 0
        ах, еще SQLAlchemy таки не до конца использует :(
        без нее никуда…

        SQLAlchemy includes C extensions which provide an extra speed boost for dealing with result sets. Currently, the extensions are only supported on the 2.xx series of cPython, not Python 3 or Pypy.
        • 0
          В SQLAlchemy всё почти отлично. Она работает в полном объеме. Пусть и не так быстро, как может.
  • +3
    Всё-таки основное различие в философии:
    Pyhon: There should be one — and preferably only one — obvious way to do it.
    Ruby: I'd rather provide many ways if it's possible, but encourage or guide users to choose a better way if it's possible.
  • 0
    Чем больше похожи языки, тем больший это повод для холивара. Наиболее сильные межвидовые столкновения происходят у близких видов (в биологии).

    Когда GIL выпилите?
    • 0
      Еще очень нескоро. Судя по тому, что регулярно возникают выпиливающие движения, довольно быстро сдувающиеся.
    • 0
      Скорее всего, в Руру справлятся с GIL быстрее чем в CPython, с помощью transactional memory. Не хотите GIL сейчас — попробуйте Jython.
      • –1
        Ну-ну. Еще одна вандервафля.

        Если transaction memory выстрелит — отлично. Как по мне, это идеологически хороший подход, который обрывается на IO.

        Я три года назад много работал с PEAK trellis а потом с переработкой от Сергея Щетинина. Общее впечатление: идея хороша, но не вполне ложится на привычные представления. И как решить вопрос один раз и для всех — не представляю. Слишком много побочных эффектов. Если у Риго из PyPy получится — буду очень рад. В любом случае внимательно слежу за развитием.
    • 0
      GIL не сломан — не надо его чинить. Практика показывает, что пользы от него больше, чем вреда. Те редкие случаи, когда нужен параллелизм логики, например числодробилки — делаются процессами.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.