PM и ведущий разработчик в продуктовой компании
  • Отчет: участие команды dou в соревновании ICFP Programming Contest 2007

    import array

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

  • Отчет: участие команды dou в соревновании ICFP Programming Contest 2007

    Фу. Гуглить репозиторий конкурентов — не спортивно. (К тому же — запрещено правилами).

    Да, не спортивно.

    RulesSubmissions: You can submit your solutions for the lightning division until 24 hours into the contest. Your solution for the 72-hour division should obviously be submitted within 72 hours into the contest.To qualify for any prize, you will have to submit your contest materials. Contest materials may include any programs and documentation you have written in order to solve the task. You can submit your contest materials by sending them to icfp@cs.uu.nl. We will accept contest material submissions until three hours after the end of the contest. This deadline also applies to the lightning division.Teams: This is an open contest. There is no entry fee or need to pre-register. Teams may work from any location.Teams with members from the faculty, students, or staff of the Information and Computing Sciences department of Utrecht University are not eligible for any of the Prizes.A team consists of every person who contributes ideas or code towards a submission. Individuals may only be member of a single team and teams may not divide or collaborate with each other once the contest has begun.Teams may have any number of members.Language and tools: Teams may work in any programming language (s) that they wish. They may employ any computational resources at their disposal.

  • Отчет: участие команды dou в соревновании ICFP Programming Contest 2007

    ; -) pourqoi pas?

  • Отчет: участие команды dou в соревновании ICFP Programming Contest 2007

    адепта читало наверное пол-рунета. так что не надо. в теории оно все красиво, а на практике первый блин всегда не очень.

  • О пользе унификации и вреде предубеждений

    к сожалению ссылка дает 404.

  • О пользе унификации и вреде предубеждений

    Harold Abelson and Gerald Jay Sussman. Это отсюда, второй абзац сверху: http://mitpress.mit.edu/sicp/f.... Красивая цитата.

    Она мне тоже нравится. Только я ее периодически нахожу и теряю. =)

  • О пользе унификации и вреде предубеждений

    Пожалуйста, укажите автора цитаты № 3.

  • 5 вещей, которые мне не нравятся в Python

    Товарищ koder привел мощную критику lazy_something, однако он глубко не вникал, поэтому она хоть и кажется правдоподобной., но таковой не всегда является.

    1) lazy_import — идея неплохая но, к сожалению, очень слабо применимая, причем ее обязательно нужно делать «вручную», автоматически питон это не сделает.

    Нет, не сделает. В самом питоне оно не встроено, поэтому не сделает. В проекте Базар ленивый импорт делается так:

    from brzlib import lazy_importlazy_import.lazy_import("""from bzrlib import error, osutils""")Как видно из этого примера, добавляются 3 строчки-обвертки, а внутри используется обычный импорт-синтаксис питона.

    а)Зачастую импорт идет не import something, а from something import x,y,zкак легко понять никакой lazy в таком случае не поможет.

    Как показано в примере выше — помогает. Замечание мимо кассы.

    б)Некоторые модули делают разные умные(или не очень ;) вещи при импорте, которые должныбыть сделаны именно в момент импорта.

    Пример неудачный. Чем ленивый импорт в этом случае будет отличаться от импорта скажем внутри какой-то функции?

    def foo(arg): import spam return spam.eggs(arg)

    try: if dt == nnn: import XXXexcept: sys.stderr.write («Can’t load appropriate plugin for nnn exit.») sys.exit (1) В этом случае весь lazy выйдет полным боком т.к. для того что-бы определитьчто утилита не подходит для данного случая придется ее слегка поисполнятьи только потом Вы узнаете что она не подошла.

    Делать sys.exit (1) только потому, что что-то не импортируется — это плохой стиль. Замечание опять же мимо кассы, потому что ленивый импорт следует применять тогда, когда он нужен, а не где попало.

    в) Автоматическим lazy_import невозможно такое обработать (приведен упрощенный пример, все может быть гораздо хуже)

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

    2) lazy_evaluated данные.Тут все сложнее, если сразу — то они автоматиски совсем никак не возможны, а неавтоматически Вы можете сделать их сами, только толк от них будет вкрайне редких случаях.

    Удивительно, и для чего же в Питоне duck-typing??? Подменить в ран-тайме даже один класс другим можно, а вы вот так, с места в карьер. В вашем примере не хватает одной малости. Lazy данные так всегда и остаются lazy. И все время будет срабатывать getattr. Lazy должен быть временным промежуточным объектом, который подменяется на реальный при первом обращении. Например, смотрите в исходниках Базар модуль lazy_regexp, который позволяет откладывать компиляцию регулярного выражения до первого использования.Все остальное изложено вами верно, у ленивых вещей в питоне много ограничений, поскольку они реализуются искусственно, поэтому можно найти еще полмилиона причин почему они не будут работать в вашем коде. В коде Базар они работают и дают реальный выигрыш. Все остальное — спор о вкусе ананасов.

    И на последок — всем советчикам по кардинальному улучшению питона.Оформите свои предложения на английском и запостите в python-dev

    Да, это ценное предложение. Учитывая, что патчи для исправления ошибок в самом питоне (не добавление новой функциональности!) лежат годами на sf.net, а теперь в новом раундап трекере, то, да, кардинально улучшать питон бессмысленная затея. В проекте Базар никтоне ставит перед собой такую задачу. Нам нужно, чтобы Базар работал как задумано. Поэтому мы сами переписываем неустраивающие части питона под себя. Никто в python-dev никакие депеши не шлет.

  • 5 вещей, которые мне не нравятся в Python

    bialix, а для чего собственно Python недостаточно быстр? (Т.е. где же это lazy evaluation спасает ситуацию?)

    Если говорить без конкретики — когда у вас есть много разнородных данных, но для выполнения каких-то операций не нужно обрабатывать их все сразу.Например, у вас есть база каких-то однотипных элементов информации, при этом каждый элемент хранит много кусочков информации о разных аспектах. Допустим какждый аспект нужно как-то предобработать (превратить в некий питон-объект) для последующей массовой обработки всей базы. Если вы не знаете заранее, какие именно аспекты будут учавствовать в обработке, то удобно не делать предобработку всей имеющейся информации, а оставить эту предобработку как ленивую операцию, которая будет выполнена перед тем как данные будут реально востребованы.Касательно lazy import. Как все знают при первом импорте модуль не только компилируется в байт-код, но и исполняется. Если в вашей программе куча импортируемых модулей, которые не обязательно испольуются все сразу, а некоторые операции вообще нуждаются в минимальном наборе импортируемых данных — вы получите большой оверхед при старте приложения. Чтобы уменьшить этот оверхед целесообразно использовать ленивый импорт.Все сказанное выше относится к тем приложениям, которые предназначены к выполнению множества разнообразных операций над единым набором входных данных. Для приложений построенных по принципу — делать хорошо только одну вещь, такая ленивость может и не дать никакого эффекта.

  • 5 вещей, которые мне не нравятся в Python

    * нет iifhttp://lambda-the-ultimate.org...* нет встроенной поддержки lazy evaluation выражений* dict.setdefault: аргумент default должен быть lazy evaluated

    Не так давно в комментах про обсуждение ФЯ некто указал, что мои вопросы про словари в Хаскеле сводятся к тривиальному «как писать на Хаскелле питон-программы». Здесь аналогичный случай, только наоборот.Однако, проблема эта есть. Питон недостаточно быстрый язык, и всякие ленивые штучки — это реальный ускоритель. Только они отсутствуют в ядре языка, и это не есть гуд. Приходится изобретать всякие костыли.Хотя, иногда костыли получаются очень даже ничего. Например, реализация ленивого импорта модулей: чтобы не импортировать сразу все, а только по мере надобности, это очень интересная вещь. Реализована (наверное первыми) в исходниках Mercurial, под названием demandload. Затем эту идею Джон Майнел из команды Bazaar перенес ее в базу кода bzr и попутно внес некоторые правильные изменения (модуль lazy_import). Так что (кому интересно) — можно и поглядеть.

  • Мой любимый неторопливый питон

    Товарыш koder вышел на тропу войны??? Ховайся хлопцы. (Всем жарко, не только вам, так что иногда стоит сливать кипяток.) В целом я написал несерьезную и в чем-то провокационную статью. Признаюсь.Перечитайте ее название. Про сконс можно говорить долго и нудно. Начал его пользовать два года назад и периодически читал список рассылки (как user, так и dev). Вы привели ссылки на обсуждения 2004 года. Я читал в 2005−2006 годах. Проблемы все еще оставались. И в 2007 году они никуда не делись. У сконса вообще очень жесткая политика разработки, может последний год что-то поменялось, не знаю.Пока что для меня панацеей от медлительности питона было и остается использование быстрой машины.В дискуссии про С++ влазить не буду, потому что я не люблю этот язык.

  • Мой любимый неторопливый питон

    Медленно работают? А есть причины полагать что можно быстрее? Может просто действительно данных очень много?

    Есть причины полагать, что да. Эта причины — программы-конкуренты.Но данных действительно очень много. Порой.В общем еще одна вещь, от которой спасает только быстрая машина — это очень медленный старт самого интерпретатора Питона. Вы пробовали когда-нибудь запустить Питон на Целероне 300 МГц? Вот когда узнаешь, что значит слово «терпение» : -)

  • Мой любимый неторопливый питон

    Теперь по делу собственно: 1) В основном низкая скорость обусловлена кривым алгоритмом, а не языком

    А вот Вы лично и сходите в список рассылки тех же docutils и scons и поучите их уму-разуму. А то ребята который год не могут правильный алгоритм выбрать.Если честно — все написанное Вами настолько тривиально и избито... Однако проблема все равно имеет место быть. И будет. И пока что решается только одним путем — использования самого быстрого компьютера из имеющихся.

  • Инфраструктура для интегрированного тестирования ПО

    Андрей, дай ссылку на asgard, пожалуйста. А то гугля к германской мифологии отсылает.

  • Инфраструктура для интегрированного тестирования ПО

    очень хорошо.

  • Вышел Bazaar 0.15

    вы про это: "The confusing array of concepts puts me off with Bazaar..."ну я право не знаю... Когда разберешься там все становится прозрачно и каждый из разных вариантов конфигурации полезен в разных условиях. Хотите узнать об этом больше — добро пожаловать в группу ru_bzr (http://groups.google.com/group...)

  • Вышел Bazaar 0.15

    2Павел: вот достаточно свежее сравнение, с большинством выводов в котором я согласен: http://permalink.gmane.org/gma...

  • Программистские ошибки для чайников

    что такое «БЖД»?

  • Плюсы работы в команде. Фрилансеру на заметку

    пролетарии всех стран объединяйтесь

  • Руководство Марка Андерсена по планированию карьеры, часть 2: навыки и образование

    нормальная статья и нормальный перевод. поскольку она ориентирована на тех, кто еще только начинает учиться или только-только закончил ВУЗ, то она вполне адекватна./Подумал о том, что надо бы получить MBA/

← Сtrl 1... 5678910 Ctrl →