Pull to refresh

Comments 31

Это такой намёк на то, что её можно скопипастить в топик.
добротная кстати раскрашивалка. Запоминается — легче не придумаешь)
UFO landed and left these words here
тот у кого всегда в голове висел дурацкий вопрос на счет реальной скорости итераторов при перещелкивании простых значений — меня поймёт. Я наверное с год терпел пока наконец не сел и не смастерил быстренько все что там вверху.

А запостил сюда потому что до глубины души был уверен что простой цикл итератор разорвёт как тузик грелку. Только потом уже когда залез в исходники itertools.c — понял что там далеко не все так просто)
кхм… а может быть с «ничего лишнего» я и немного перегнул палку…
В тьетьем питоне в направлении итераторов серьёзно поработали, и itertools там вроде бы больше не нужны.
В частности: range, zip, filter, map — сразу сделаны итераторами.
а они там в поставке питона присутствуют? Если да — то всё таки нужны. А если нет — то и впрямь значит не нужны =). Очевидно, Ватсон).
стоит иметь ввиду что itertools это все таки сам питон тоже. Стандартная библиотека, а не кем-то на коленке написанная.
да, про отсутствие необходимости itertools я погорячился.

но всё, что у вас в примерах — izip, islice, xrange из itertools перенесены в core
и таки надо учиться писать алгоритмы которые не используют «статические» списки.
более функциональное программирование.
иногда очень уж эффективно. Это фактически аналог ссылок на пямять в си с небольшим овертаймом.

Так, например, надо было мне в базу почти полмиллиона записей засунуть (не спрашивайте зачем — правдо надо). Для них данные — в трёх списках. Казалось бы собрать один список и отдать его в executemany будет круто, но требуется почти 2 секунды лишнего времени на сие действо (а сам запрос — 3сек).

А вот так — 3секунды на запрос и 0.0000 на формирование «списка» )
data = ([node_id] + grant + extra for (node_id, grant, extra) in izip(self.tree_data, self.grant_data, self.extra_data))
я чото недогоняю, наверно.
data = (...) — это как?
генератор же! ай-ай-ай как не стыдно):

In [115]: x = ([z, z+1] for z in [1,2,3])
In [116]: type x
--------> type(x)
Out[116]: <type 'generator'>
In [117]: x.next()
Out[117]: [1, 2]
In [118]: x.next()
Out[118]: [2, 3]
In [119]: x.next()
Out[119]: [3, 4]
In [120]: x.next()
---------------------------------------------------------------------------
StopIteration Traceback (most recent call last)

/home/mocksoul/workspace/ipidev/repos/ipimanager/topic-access-refactor/in ()
В питоне эти оплоты функционального программирования иногда очень в тему приходятся. Так — как минимум некоторые вещи можно сделать весьма компактными. А т.к. внутри функциональных выражений не может быть присваивания (априори) — питон оптимизирует их, т.к. не надо следить за переменными.
о! стыдно! :)

ну, по сути, я это и имел ввиду, говоря «ещё надо научиться использовать» :)
насиловать себя пытаясь это понять, однако, не стоит. Само придёт. Можно форсировать канеш, например, покопавшись в erlang, lisp и иже с ним).
если не «насиловать», то можно так и остаться на уровне алголо-ориентированных алгоритмов по урокам паскаля и це.
ну главное всё таки результат, а на Си результаты бывают огого какие)
существенную роль играет всёже и эффективность разработки (по времени, по соотношению траха/фана, итд).

владея более широким спектром приёмов программирования — эту стоимость можно существенно сократить.
а владея другими подходами программирования — так это на порядок.

эта эффективность иногда кажется даже важнее, чем эффективность результата.
это в соседнем окошке открыто и было :)
но там дисклэймер: «это для тех, кто разработкой зарабатывает, а не развивается» :)
написал над кодом что вообще в коде происходит. Учитесь наздоровье =).
ну я понял, что происходит.
и глядя на это, задумался, что у меня всё нифига не эффективно.

вобще, за пост спасибо.
весьма наглядные примеры.
так совпало, что я какраз сейчас обрабатываю списки, и накопилось много ужасного кода.
Only those users with full accounts are able to leave comments. Log in, please.