ээ

кек у тебя содержит список туплов слово-колво

второй цикл по j лишний)

for j in i - дебильно-то как

for word, count in kek: # ты хочешь это

у тебя j равен то слову, то числу

второй цикл по j лишний)

разве?

kek = [('word', 10), ('fuck', 9), ('you', 8)]

первый цикл перебирает i = 'word', 10 i = 'fuck', 9 i = 'you', 8

да, дошло

второй: первый цикл перебирает i = 'word', 10 j = 'word' j = 10 i = 'fuck', 9 ...

а потом ты делаешь 10[0]

да, будешь своё говно пейсать, не забывай про случаи когда в топ10 будет меньше 10 слов

не, тут конкретно вывести 10

это задачки из нового модного devman

ну тогда или re.findall(r'[A-Za-zА-Яа-яЁё]+') или re.splitl(r'[^A-Za-zА-Яа-яЁё]+')

не знаю как в 3, а во 2 делал ur'[А-Яа-я] - включает ё

не знаю как в 3, а во 2 делал ur'[А-Яа-я] - включает ё

не включает

ни в 3, ни в 2. достаточно посмотреть коды

не знаю как в 3, а во 2 делал ur'[А-Яа-я] - включает ё

In [13]: print re.match(ur'[а-я]+', u'ё') None

In [13]: print re.match(ur'[а-я]+', u'ё') None

Может по юникод код поинтерам? http://jrgraphix.net/r/Unicode/0400-04FF

Может по юникод код поинтерам? http://jrgraphix.net/r/Unicode/0400-04FF

в смысле? я просто показал, что во втором питончике это не пашет

>>> ord(u'а'), ord(u'я'), ord(u'ё') (1072, 1103, 1105)

1105 не попадает в интервал 1072-1103

возможно, потому, что ё в юникодной таблице реально на другом месте

угу

Тогда писать [а-ё]

А какой символ у 1104

Тогда писать [а-ё]

Ё вообще особняком

хуевое предложение, короче

вон выше линк на блок кириллицы

Я скинул?

найди там ё и Ё и сделай выводы

Может по юникод код поинтерам? http://jrgraphix.net/r/Unicode/0400-04FF

Так 0400 не похоже на 1к,странно

Я от фонаря

вопрос в общем что нужно - кириллицу вообще, или подмножество только русского

0400 = 1024

А бля

шестнадцатиричная же

Это же 10-16

Тогда да

есть в питоне продукт?

product([1,2,3,4])=24

именно встроенный?

это не продукт...

>>> math.factorial(4) 24

>>> math.factorial(4) 24

это да

стоп. тебе надо перемножить все числа?

а ежели [2,2,6,8,13]

стоп. тебе надо перемножить все числа?

да

ну офк можно редусом

ток это некрасиво

reduce(operator.mul, x)

почему некрасиво?

ВОТ

редьюс это как раз про A1 op A2 op A3 op A4

operator.mul

я просто думал о редусе с лямбдой

reduce(operator.mul, x)

спасибо

>>> from functools import reduce >>> from operator import mul >>> reduce(mul, [2, 2, 6, 8, 13]) 2496

Привет! Никто не сталкивался с тем, что map дольше работает чем использование функции на том же наборе данных в цикле for.

Привет! Никто не сталкивался с тем, что map дольше работает чем использование функции на том же наборе данных в цикле for.

т.е. просто for obj in data: do_smth(obj)?

т.е. просто for obj in data: do_smth(obj)?

Да...так...это быстрее чем map

т.е. просто for obj in data: do_smth(obj)?

Работаю с листом из строк...и мэп существенно дольше

интересно :о а замеряешь как? timeit должен быть точнее

(я не знаю почему так, просто интересно)

потому что мэп собирает результаты

а фор нет

блин, логично

вообще мэп в среднем по палате должен выигрывать

потому что дольше времени проводит в си

Неа

результаты профилирования в студию

В цикле я сам собираю результаты в лист Типа bar.appebd

Не под рукой

а чё не list comprehension тогда?

D:\>py -mtimeit -s "r=[]; f=lambda x:x+1" "for i in range(10000): r.append(f(i))" 1000 loops, best of 3: 1.88 msec per loop D:\>py -mtimeit -s "r=[]; f=lambda x:x+1" "for i in range(10000): r.append(f(i))" 1000 loops, best of 3: 1.87 msec per loop D:\>py -mtimeit -s "f=lambda x:x+1" "r=list(map(f, range(10000)))" 1000 loops, best of 3: 1.22 msec per loop D:\>py -mtimeit -s "f=lambda x:x+1" "r=list(map(f, range(10000)))" 1000 loops, best of 3: 1.22 msec per loop D:\>py -mtimeit -s "f=lambda x:x+1" "r=[f(x) for x in range(10000)]" 1000 loops, best of 3: 1.34 msec per loop D:\>py -mtimeit -s "f=lambda x:x+1" "r=[f(x) for x in range(10000)]" 1000 loops, best of 3: 1.21 msec per loop не очень репрезентативно, но в целом мап шустрее обычно

Я все три года был уверен что мэп быстрее пока случайно не посчитал примитивно oldatime -time.now

но надо мерять конкретный случай чтобы сказать наверняка

Я все три года был уверен что мэп быстрее пока случайно не посчитал примитивно oldatime -time.now

ну и зря

правильно замерять - тоже уметь надо

Я думаю, что в случае с примером с числами...не то

хз, версия питона тоже роль играет

ибо в двойке мап возвращает честный лист, а в тройке - итератор

Да я знаю

если исходить из того что тело цикла/функции будет работать с одинаковой скоростью, то в целом накладные расходы мапа должны быть чуть-чуть ниже

но на фоне основного тела вообще мизер должен быть

если же у тебя радикально разные результаты - то хотелось бы увидеть код

и замеры не через time.now, а timeit.default_timer

и замеры не через time.now, а timeit.default_timer

вот! оч важно

Ок. Попробую timeit

Просто проект разрастается... и только сели немного его отрефакторить...стали уже считать время

timeit делает несколько интересных вещей: 1) выбирает разные функции времени в зависимости от платформы (у них разная точность - time.time/time.clock) 2) выключает сборку мусора на время замера (это позволяет не искажать результаты, зато приводит к некислым расходам памяти) 3) вызывает через ексек для нивелирования вызовов собственно профилера

dict.values() будут возвращены по порядку?

dict.values() будут возвращены по порядку?

Нет

т.е. есть дикт a={0:'a',1:'b'} list(a.values()) всегда будут распологатся по порядку возрастания их ключей?

В словаре ключи не в порядке возрастания идут

а с каких пор values стали ключами? 8)))

окей тогда вопрос если у меня в словаре ключи - 0..n как мне вернуть лист в котором в позиции ключа будет соответствующее значение?