python2 vs python3 range

правильно ли оборачивать range в list в python3?

нет, конечно

но ведь range совсем не так работает как в python2

правильно ли оборачивать range в list в python3?

ЕМНИП в py3 range работает как xrange в py2, так что если нужно делать несколько проходов по результату то это может иметь смысл.

Задача у меня искать по паттерну в файле строку подходящую

наверное надо взять библиотеку подходящую?;-)

там либа не очень решает мои проблемы, требуется экзотическое решение под нужды

Неубедительно.

Если бы было приведено время обработки скажем гигового текстового файла …

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

Точно были какие то модули для поиска вхождений подстроки в строку по шаблону.

Да, по крайней мере нужно сделать много заходов в рамках одного скрипта а не один, ну или руками мерять время в скрипте. Непонято сколько из этого времени уходит на запуск (скорее всего основное и уходит)

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

правильно ли

ты ещё не готов. тебе нужно больше практиковаться, чтобы постичь дзен.

если нужна скорость, то пиши на сишке.

я бы посмотрел на твой скрипт.

[~]-[%] time python2 -c ''

real	0.02s
user	0.02s
sys	0.00s
[~]-[%] time python3 -c ''

real	0.06s
user	0.05s
sys	0.00s

Понимаешь?

Твое сравнение ничего не показывет. Python3 стартует медленнее, чем python2.

понял, щас думаю в сторону cython, так как в C я дилетант

да я наброски закину в теч. суток

понимаю, единственное что я щас понял, делать все на cython

задача достичь хотя бы приблизительной скорости поиска aka «grep -r „string“ ./dir» на python3

естественно греп я никогда не обгоню, но интерес обработки и поиска текста на подобии с потерями скорости (не конской) приемлем.

да я наброски закину в теч. суток

Ждем результаты анализа.

скрипт для работы с текстом

python

Perl же для этого придумали.

к сожалению или к счастью не приходилось с ним работать толком)

к сожалению или к счастью не приходилось с ним работать толком)

Можно сказать и по другому - «к не счастью и к великому сожалению не приходилось с ним работать толком) никогда»

логичнее было бы проверять на

[i for i in xrange(len(string))]

и

[i for i in range(len(string))]

ну и нужно не просто командой time проверять, я прямо в коде вычислять дельту между

start = time.time()

# код

end = time.time()

а то так херня выходит. А еще надо делать как минимум прогонов не один раз. В общем-то можешь ничего не делать там одна и та же скорость в среднем.

задача достичь хотя бы приблизительной скорости поиска aka «grep -r „string“ ./dir» на python3

А зачем для этого делать print(list(range(len(string))))?

задача достичь хотя бы приблизительной скорости поиска aka «grep -r „string“ ./dir» на python3

Меняй методичку, жертва пропаганды. Ты упрешься в скорость диска и/или файловой системы. Так что можешь не сранвнивать - скорость будет одинакова.

Откуда ты знаешь может он себе намапит в память и будет оттуда грепать, это конечно никак не спасет от того, что надо все еще читать с диска, но тут сам понимаешь, так что меняй методичку жертва пропаганды ио баунда.

может он себе

Он даже сам себе не сможет, этот сравниватель скорости неизвестно чего.

намапит в память и будет оттуда грепать

То что можно намапить в память, автоматом замапится в буферы/кеши. Не занимайся тройной и более буферизацией. Помножен на ноль

Ведь ты понятия не имеешь сколько у него памяти и что он делает возвел себя в нулевую степень и победил. Хотя, первая часть скорее соответствует действительности.

Ведь ты понятия не имеешь сколько у него памяти

Конечно же ты, птушник, знаешь.

что он делает

Он сам не знает, что делает.

Никто не знает пыль запартная, но никто и не спорит, что он знает что делает, вообще вся эта тема похожа на потуги дошколенка который где-то прочитал жертва пропаганды опасения таких же жертв пропаганды, что range теперь медленнее потому что надо заворачивать в list пропаганда дошколят дошколятам ведь заворачивать надо только если хочешь получить list, а для чего он ему нужен он так и не сказал, да и вообще ничего толкового не сказал…

В сторону timeit посмотри, он нормально измерит.

На cython обычно осмысленно делать только числодробление, и то для этого numba есть.

Сдается мне, фигню ты там делашь.

задача достичь хотя бы приблизительной скорости поиска aka «grep -r „string“ ./dir» на python3

и, написав решениее на cython, ты решишь совсем другую задачу. знать бы зачем.

моя задача сделать бинарник с удобным и более менее быстрым поиском по патерну в больших файлах, для этого есть греп - да, но задача максимально это упростить и добавить некоторые фичи которые требуются мне и некоторым людям для рутинных задач не только на *nix системах, но и на форточке.

Возможно фигня да, но вроде получается что то и не плохо, готовый линк в этот топик скину на GH реп

задача максимально это упростить и добавить некоторые фичи которые требуются мне и некоторым людям для рутинных задач не только на *nix системах, но и на форточке.

ag / ripgrep?

заметил что python3 медленее работает с поставленной задачей, пример

А может ты замерил время запуска интерпретатора, а не выполнения задачи?

Задача у меня искать по паттерну в файле строку подходящую

чем регулярки не устроили?

Задача у меня искать по паттерну в файле строку подходящую

re в помощь

а регулярки разве быстрее чем поиск по паттерну при разборе строки?

Это не риторический вопрос, а вопрос для изучения что бы в дальнейшем было проще выполнять разные задачи

скорее да чем нет, замерял то я не само выполнение задачи кодом, а запуск интерпритатора (виртуальной платформы, кому как удобнее), и последующее выполнение непосредственно кода

Смотря как написаны, однозначно, регулярки удобнее на порядок, чем возня с разбором строки руками. Пример тестовой строки в студию.