DjangoBB LoFi version

Полная версия: Генерация списка словарей из текстового файла

Начало » Python для новичков » Генерация списка словарей из текстового файла

1 2 3 4 5 6 7 8

py.user.next

Авг. 22, 2015 20:21:50

Shaman
лучше учесть все случаи

Функция данной регулярки заключается в выборе полей, она не должна заниматься чисткой данных. Чисткой данных должен заниматься специальный участок, чья функция именно в этом и заключается. Так можно менять поиск независимо от чистоты данных и менять чистку независимо от целей поиска.

А в данном случае он у него где-то неправильно создаётся, из-за чего питон не может привести концы строк к единому виду (поставить регулярке чистые данные).
То есть вот эти re.sub'ы - тоже неправильно, надо файл отредактировать снаружи скрипта.

metotron

Авг. 22, 2015 20:54:31

ну пока поменять алгоритм создания я не могу - приходится юзать то что есть

Shaman

Авг. 22, 2015 20:56:41

py.user.next
Функция данной регулярки заключается в выборе полей, она не должна заниматься чисткой данных. Чисткой данных должен заниматься специальный участок, чья функция именно в этом и заключается.

Всё проще: эта регулярка вообще ничего не чистит - она просто берёт данные из того что дают.

py.user.next

Авг. 22, 2015 23:50:58

Shaman
эта регулярка вообще ничего не чистит

Как не чистит, учитывает наличие \r, которого не должно быть. Из-за этого ты её и поменял с \n на \s+. То есть подчищает какой-то косяк, пришедший снаружи.
Это не эквивалентные выражения.
Вот у него там текста на 500 килобайт, совпадение с одним симоволом будет работать быстрее на каждой записи.

Shaman

Авг. 22, 2015 23:59:21

py.user.next
Как не чистит, учитывает наличие \r, которого не должно быть.

Ничего там не чистится. У нас уточнилась спецификация формата входящих данных и мы это учли в коде. Всё! А то, что там должно быть и чего там быть не должно - всего лишь твои домыслы.

py.user.next
совпадение с одним симоволом будет работать быстрее на каждой записи.

На сколько микропроцентов?

py.user.next

Авг. 23, 2015 00:20:45

Shaman
На сколько микропроцентов?

[guest@localhost ~]$ python3 -mtimeit -s "import re" "re.findall(r'\n', 'abc\n' * 10)"
100000 loops, best of 3: 3.65 usec per loop
[guest@localhost ~]$ python3 -mtimeit -s "import re" "re.findall(r'\s', 'abc\n' * 10)"
100000 loops, best of 3: 5.59 usec per loop
[guest@localhost ~]$ python3 -mtimeit -s "import re" "re.findall(r'\s+', 'abc\n' * 10)"
100000 loops, best of 3: 6.41 usec per loop
[guest@localhost ~]$

Тут в два раза, но это самый простой случай. А там полей несколько, можно и замерить для там.

Shaman

Авг. 23, 2015 09:31:53

py.user.next
Тут в два раза, но это самый простой случай. А там полей несколько, можно и замерить для там.

Отлично! А теперь то же самое для

with open ("somefile.txt", "r") as myfile:
    data=myfile.read()
    data = re.sub('\r','',data)
    data = re.sub('\n\n','\n',data)

пожалуйста! И добавить туда время на разбирательства в случаях отклонения от первоначального формата.
Для полноты так же нужно посчитать затраты на “(\d+)” - вдруг от них тоже стоит отказаться?

py.user.next

Авг. 23, 2015 13:03:02

Shaman
Для полноты так же нужно посчитать затраты на “(\d+)” - вдруг от них тоже стоит отказаться?

С чего это вдруг? \d+ - необходимое условие, иначе как цифры накапливать?
(Регулярка, к тому же, ещё и читаемой должна быть.)

Shaman
А теперь то же самое для

Да надо просто файл через sed снаружи прогнать, если невозможно исправить алгоритм, который порождает его (со смешанными концами строк).

Кстати, если есть этот костыль (re.sub()), то твоя регулярка не только будет дольше искать, но и работать впустую. Ты же привязал таким образом регулярку к побочному содержимому, которое ещё может быть удалено каким-нибудь способом.

Shaman

Авг. 23, 2015 16:19:50

py.user.next
С чего это вдруг? \d+ - необходимое условие, иначе как цифры накапливать?

А это тонкий намёк на необходимость и других условий.

py.user.next
Да надо просто файл через sed снаружи прогнать, если невозможно исправить алгоритм, который порождает его (со смешанными концами строк).

Способ не важен, важно правильно сравнивать времена отработки.

py.user.next
Кстати, если есть этот костыль (re.sub()), то твоя регулярка не только будет дольше искать, но и работать впустую.

Допустим, у меня хватает благоразумия не фильтровать дважды.

py.user.next
Ты же привязал таким образом регулярку к побочному содержимому, которое ещё может быть удалено каким-нибудь способом.

Почему ты считаешь содержимое побочным? Не знаешь почему до сих пор некоторые утилиты заикаются от отсутствия перевода строки в конце файлов, а другие в таких случаях намекают на некий “плохой стиль”?
С таким же подходом числовые данные могут быть тоже удалены каким либо образом и вообще на вход могут подать мусор (после того как грибы во рту вырастут).

Не могу понять к чему этот спор? Не ожидается в разделителях ничего лишнего - ловить только нужное число пробелов в регулярке, но если line endings идут разных форматов, так самое место в регулярке это и учитывать, а не городить никому не нужные очистительные каскады, жрущие так всеми нами любимую память и сопоставимое количество процессорного времени.

Iskatel

Авг. 23, 2015 16:53:28

«Если у вас была одна проблема, и вы решили использовать регулярные выражения, то теперь у вас есть две проблемы»

Конечные автоматы гораздо быстрее и надежнее

out =[]
pos = -1
with open('d:\\info.txt') as f:
    for line in f:
        if line[0] == '-':
            pos = 0
        elif pos == 0:
            mt = int(line.split(':')[1].strip().split(' ')[0])
            pos = 1
        elif pos == 1:
            mf = int(line.split(':')[1].strip().split(' ')[0])
            pos = 2
        elif pos == 2:
            buf = int(line.split(':')[1].strip().split(' ')[0])
            pos = -1
            out.append({'MemTotal':mt,'MemFree':mf,'Buffers':buf})