Комментарии 31
А как по мне — доступно)
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
тот у кого всегда в голове висел дурацкий вопрос на счет реальной скорости итераторов при перещелкивании простых значений — меня поймёт. Я наверное с год терпел пока наконец не сел и не смастерил быстренько все что там вверху.
А запостил сюда потому что до глубины души был уверен что простой цикл итератор разорвёт как тузик грелку. Только потом уже когда залез в исходники itertools.c — понял что там далеко не все так просто)
А запостил сюда потому что до глубины души был уверен что простой цикл итератор разорвёт как тузик грелку. Только потом уже когда залез в исходники itertools.c — понял что там далеко не все так просто)
кхм… а может быть с «ничего лишнего» я и немного перегнул палку…
В тьетьем питоне в направлении итераторов серьёзно поработали, и itertools там вроде бы больше не нужны.
В частности: range, zip, filter, map — сразу сделаны итераторами.
В частности: range, zip, filter, map — сразу сделаны итераторами.
а они там в поставке питона присутствуют? Если да — то всё таки нужны. А если нет — то и впрямь значит не нужны =). Очевидно, Ватсон).
What’s New In Python 3.0: Views And Iterators Instead Of Lists
но кое что из itertools таки ещё полезно.
но кое что из itertools таки ещё полезно.
и таки надо учиться писать алгоритмы которые не используют «статические» списки.
более функциональное программирование.
более функциональное программирование.
иногда очень уж эффективно. Это фактически аналог ссылок на пямять в си с небольшим овертаймом.
Так, например, надо было мне в базу почти полмиллиона записей засунуть (не спрашивайте зачем — правдо надо). Для них данные — в трёх списках. Казалось бы собрать один список и отдать его в executemany будет круто, но требуется почти 2 секунды лишнего времени на сие действо (а сам запрос — 3сек).
А вот так — 3секунды на запрос и 0.0000 на формирование «списка» )
Так, например, надо было мне в базу почти полмиллиона записей засунуть (не спрашивайте зачем — правдо надо). Для них данные — в трёх списках. Казалось бы собрать один список и отдать его в 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 = (...) — это как?
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 и иже с ним).
если не «насиловать», то можно так и остаться на уровне алголо-ориентированных алгоритмов по урокам паскаля и це.
ну главное всё таки результат, а на Си результаты бывают огого какие)
существенную роль играет всёже и эффективность разработки (по времени, по соотношению траха/фана, итд).
владея более широким спектром приёмов программирования — эту стоимость можно существенно сократить.
а владея другими подходами программирования — так это на порядок.
эта эффективность иногда кажется даже важнее, чем эффективность результата.
владея более широким спектром приёмов программирования — эту стоимость можно существенно сократить.
а владея другими подходами программирования — так это на порядок.
эта эффективность иногда кажется даже важнее, чем эффективность результата.
Спасибо:)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Why itertools rocks