kb
27.12.2012 08:35
Как я пришел со своим питоном и показал всем http://nponeccop.livejournal.com/304585....
29 comments
recommend
bookmark
subscribeDo you really want to delete ?
- within threads
- within tags
- within users
Как я пришел со своим питоном и показал всем http://nponeccop.livejournal.com/304585....
Зачем в https://gist.github.com/4386447 так много комментировал, весь with? можно было бы комментировать две строки первого варианта и три строки второго. Смотрелось бы красивее.
зачем ему иметь глубокие знания во всех этих языках?
>iteritems()
ключи, хуячи, итемы, вэльюзы, хуитемы же вроде давно уже всегда возвращают итератор, вроде бы в 2.7 точно так, не?
алсо следует почитать эссе гвидо http://www.python.org/doc/essays/list2st... если мы говорим тут про скорость, а конкатенация у тебя через хуй
Мне так было быстрее, сначала закомментировать решение, а потом при имплементации второго увидел, что будет копипаста и скопировал.
Вроде только в 3м.
Всё у меня нормально с конкатенацией. Гвидо-поебень оправдывается только когда надо объединить список большой в одну строку (надо делать ",".join() или типа того). То есть, если бы надо было вернуть результатом какую-то простыню, я бы сделал "\n".join(список_с_результатом). А так — всё нормально у меня, в порядке рабочего кода.
да, в 3м. это бы сломало во 2й ветке дохуя всего, уверен.
думаю, просто интересно стало сравнивать, изначально только про х-ль речь шла (и отсутствие в нём хеш-мапов в их привычном для нас виде).
)))
тест вообще не имеет смысла, даже если не учитывать полное отсутствие методики измерения у автора
ну как это, не имеет? вполне реальная задача, вполне реальное её решение. появилась возможность разным людям собраться и посмотреть, что получится. почему "не имеет смысла"?
потому что результаты никак не связаны с языком
связаны напрямую же. Суть ведь не в том, чтоб сравнить "КАКОЙ ЯЗЫК ЛУЧШЕ".
будто кто-то будет выбирать инструмент, исходя из таблицы и подобным
еще раз, не было цели выбирать инструмент исходя из этой таблицы. была мысль сравнить инструменты на этой конкретной задаче. в случае с х-лем — довести его до уровня хотя бы перла (собственно, я так понял, отсюда и растут ноги этой таблички). а после того, как набросали кучу имплементаций — я посчитал интересным посмотреть на python и pypy, и в случае с pypy — еще раз убедиться в гениальности его авторов. ты прав в плане "выбора инструмента" в том, что для jit-дружественных задач я не буду бояться брать pypy.
лучше бы факториал считали
лучше бы sphinx прикрутили.
чтобы узнать, что Си не ест память и делает быстро, а жава ест память и делает не так быстро?
обычно Си и Джава (и эти их свойства) берутся, скорее, как точки отсчета.
я не про твой пример с пайпай, а про оп-пост, очевидно
а побеждает ПИТОН!
бойан, на псто ВСЕ уже знают, что побеждает ПИТОН
надо было вбросить решение на R, там наверняка есть оптимизации! но оп опять же хуй
хотя одновременно по памяти и временни офк не выиграть
скорее удивляет, да.
> там наверняка есть оптимизации
потому что топовое решение наверняка в лоб, хотя я не читал
//тупой штоле?
ну я же говорю, что оп-пост изначально про то, что хаскелл медленнее перла получился (что тупо, как бы), видимо, оттуда и ноги растут.