Полная ли жесть данный код на python?

Question

[Дмитрий Филимонов]

Как-то однажды нужно было написать конвертацию одного списка в другой:

[('www.ya.ru', set()), ('ya.ru', set()), ('xxx.x', set())]

И нужно из этого получить список с доменами без www, где множества, находящиеся с ними в одном tuple, объедены: [('ya.ru', set()), ('xxx.x', set())]
Писать, как это решить обычно и просто, думаю, смысла нет. Но в тот момент я находился в интерактивном питоне и писал, что идет в голову. В итоге родился ад, который лично мне не наносит никакой боли, хотя я не уверен, что это нельзя сделать проще. Скорее всего, можно, но я этим не занимался.

resolved = reduce(lambda x, y: x[:-1]+[(y[0][0], y[0][1].union(x[-1][1]))] if x[-1][0]==y[0][0] else x+y, sorted([[(i[0].split('www.')[-1], i[1])] for i in resolved]))

Но вопрос в том, что если вы бы встретили в проекте, который вам поддерживать, что-то в этом роде, как бы вы к этому отнеслись? Предположим, что под рукой у вас горячий паяльник.

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

p.s. Если кто-то решил использовать что-либо из примера выше, настоятельно не рекомендую, так как он содержит баг и, вообще, не крутой. Крутой пример для этой же задачи есть в комментариях.

С учетом этого суть вопроса топика может быть изложена иначе: жесть ли переписывать маленькие/самодостаточные алгоритмы в функциональный стиль (при наличии адекватного оформления кода и пояснений) внутри императивной программы?

Answer 1

[zed]

Жесть полная. Пишите код для людей.

Answer 2

[Rrooom]

Нормально. Главное не забывайте всё логично разбить на строки.

Comments

[zed]

Оно уже разбито, если вы вдруг не поняли :)

[Дмитрий Филимонов]

Кстати, да, если что, то разбить не проблема. То есть в идеале: разбитый код + коммент с примером.

Я думаю, что если такая штука не будет падать (а она не должна), то вряд ли будет нужда ее переписать.

[zed]

@DmitryPhilimonov согласитесь, если вы сделаете рефакторинг, да ещё и комментарии с примером накатаете, это уже будет другой код и вполне возможно, что это уже будет не жесть. Но сейчас-то вы нам написали одну чудо-строчку...

[Дмитрий Филимонов]

@zedxxx: для упрощения можно принять, что код тот же, но читаемость лучше, т.к. разбит на строки. Но, я так понял, одна строка вас смущает, но несколько строк того же кода + коммент - это уже нормально? :)

[zed]

@DmitryPhilimonov: Нет, не нормально. Я говорил про рефакторинг.

[Дмитрий Филимонов]

@zedxxx: я понял, но если радикально отрефакторить и превратить в императивный стиль, то вся суть у вопроса в топике теряется.

[Andrey Dugin]

Дмитрий Филимонов: Хороший код не нуждается к комментировании.

Answer 3

[Валентин]

Если все в одну строчку и без доки, то херово. Если бы задача упала, удалил бы эту строку и написал заново.

Answer 4

[yttrium]

'У кого длинее'

reduce(lambda x,y: (x[0],x[0].__setitem__(y[0],x[0][y[0]].union(y[1]))),map(lambda x:(re.match(r'(www\.)?(.*)',x[0]).group(2),x[1]),l),(defaultdict(set),))[0].items()

Функциональный подход. если вынести re.compile должно быть быстрее

Comments

[Дмитрий Филимонов]

Да, ваш вариант значительно лучше. Буду использовать вместо того, что выше. Также открыл для себя defaultdict, как же не хватало его, спасибо :)

Только одно не понял: валидация url не нужна, зачем использовать регексп и еще и внутри map, когда можно проще: [(i[0].split('www.')[-1], i[1]) for i in l]

[yttrium]

валидация.. а если у тебя будет WWW.mywww.ru?
А проще, красивее и главное быстрее будет вот так
[(i.replace('www.','',1), j) for i,j in l]
хитпарад раскажет вот этот скрипт

from timeit import timeit

l = "l=[('www.ya.ru', set()), ('ya.ru', set()), ('xxx.x', set())]"

setup = """
import re
r = re.compile(r'^(?:www\.)?(.*)', re.I)
""" + l
setup2 = """
import re
r = re.compile(r'^www\.', re.I)
""" + l

tests = {
    'for x + split': ("[(i[0].split('www.')[-1], i[1]) for i in l]", l),
    'for x,y + split': ("[(i.split('www.')[-1], j) for i,j in l]", l),
    'for x,y + replace': ("[(i.replace('www.','',1), j) for i,j in l]", l),
    'map + replace': ("map(lambda ij:(ij[0].replace('www.','',1), ij[1]), l)", l),
    'map + lambda() + replace': ("map(lambda (i,j):(i.replace('www.','',1), j), l)", l),  # py2 only
    'map + match': ("map(lambda x:(r.match(x[0]).group(1),x[1]),l)", setup),  # py3 compatible
    'for x,y + match': ("[(r.match(x).group(1),y) for x,y in l]", setup),  # py3 compatible
    'map + sub': ("map(lambda x:(r.sub('',x[0],1),x[1]),l)", setup2),  # py3 compatible
    'for x,y + sub': ("[(r.sub('',x,1),y) for x,y in l]", setup2),  # py3 compatible
    'map + lambda() + match': ("map(lambda (x,y):(r.match(x).group(1),y),l)", setup),  # py2 only
    'map + lambda() + sub': ("map(lambda (x,y):(r.sub('',x,1),y),l)", setup2),  # py2 only
}


def test_suit():
    for s, (t, setup) in tests.items():
        try:
            yield (timeit(t, setup=setup), s)
        except SyntaxError:
            pass

for ts in sorted(test_suit()):
    print("%.4f %s" % ts)

Несмотря на то что в python3 с re быстрее, это обман.. потому что map отдаёт генератор.
И особенно печально то что в тройке уже нет паттерн матчинга lambda (x,y):..

[Дмитрий Филимонов]

@yttrium: да, со split кривой вариант, просмотрел. Только и replace тоже не панацея: пропустит домены типа www.ru, хотя это уже менее критично, но все же.

Хитпарад интересный. И тут обман не только с re, а вообще с map: если не нужен генератор, то map будет значительно медленнее.

[yttrium]

С модулем re никакого обмана нет. Как раз re поможет исключить неоднозначность. Обман конкретно в некоторых значениях которое выдаёт хитпарад на python3, ввиду того что map отдаёт генератор. а как раз в reduce скармливать лучше генератор, это будет оптимальнее по памяти и соответственно не критично для больших списков.
Также из хитпарада видно, что предварительная декомпозиция кортежа положительно влияет на скорость.

[Дмитрий Филимонов]

@yttrium: Вы запутались в своих неточных выражениях. Изначально написали, что "re быстрее - это обман, потому что в map, который генератор отдает", на что я ответил, что "вообще весь map - обман", на что вы мне ответили, что с "re никакого обмана нет, и что весь map - обман". О чем я говорил, собственно.

В ваш вывод модно добавить, что reduce лучше не скармливать генератор, если список небольшой. Тогда он будет быстрее раза в 2-3, а оптимальность по памяти в таком случае не нужна. Тем более, что большой список - понятие растяжимое. Один кортеж такой в списке занимает около 8 байт (с 1 записью в set), можно посчитать, что будет критично в конкретном случае.

В принципе можно сделать генератор без map со всеми этими for, он почти не проигрывает в скорости. А что касается предварительной декомпозиции кортежа, то я согласен с PEP, оно действительно имеет больше минусов, чем плюсов.

[yttrium]

@DmitryPhilimonov: судя по вашему выражению "И тут обман не только с re" - я посчитал что меня не поняли, и сделал другой заход. Потому-что именно с модулем re нет никакого обмана, а конкретно в хитпараде в большинстве примеров с re есть map, который и вводит в заблуждение. Предлагаю не мерится словесными оборотами.

Согласен, зависит от конкретной задачи. Тем не менее генераторы(сопрограммы/корутины) достаточно мощный инструмент, активно использующийся в hl проектах в том же tornado и asyncio.

Какой именно PEP и какая формулировка?
Декомпозицию кортежа я имел ввиду в выражении
[(i.split('www.')[-1], j) for i,j in l]
Которое кстати больше соответствует PEP 20 чем выражение
[(i[0].split('www.')[-1], i[1]) for i in l]

[Дмитрий Филимонов]

@yttrium: вы выше писали, что печально, что в 3 питоне нет "паттерн матчинга" в параметрах функции. Мне это запомнилось, думал, вы об этом. Вот этот PEP: dinsdale.python.org/dev/peps/pep-3113

Answer 5

[VovanZ]

Я бы отформатировал его, хотя бы как-то так:

resolved = reduce(
    lambda x, y: x[:-1]+[(y[0][0], y[0][1].union(x[-1][1]))] if x[-1][0]==y[0][0] else x+y, 
    sorted(
        [[(i[0].split('www.')[-1], i[1])] for i in resolved]
    )
)

Answer 6

[Andrey Dugin]

Лютый говнокодище - что у автора, что в комментах :)

dlist = [('www.ya.ru', {1,2,3}), ('ya.ru', {4,5}), ('xxx.x', {6,7,8,9})]

Если порядок элементов не важен, то эталонный код должен выглядеть так:

from collections import defaultdict

buffer = defaultdict(set)
for domain, stuff in dlist:
    buffer[domain.lstrip('www.')].update(stuff)
print buffer.items()

Если порядок важен:

from collections import OrderedDict

buffer = OrderedDict()
for domain, stuff in dlist:
    if domain.startswith('www.'):
        domain = domain[4:]
    buffer.setdefault(domain, set()).update(stuff)
print buffer.items()

И не надо лепить нечитабельные однострочники! Но если ради научного интереса:

buffer = defaultdict(set)
map(lambda (domain, stuff): buffer[domain.lstrip('www.')].update(stuff), dlist)
print buffer.items()

Или так:

reduce(
    lambda buffer, (domain, stuff): buffer[domain.lstrip('www.')].update(stuff) or buffer,
    dlist,
    defaultdict(set)
).items()

Comments

[Дмитрий Филимонов]

Первые 2 варианта "недостаточно интересны", вторые 2, строго говоря, не однострочники, а все тот же императивный алгоритм. Кроме того, что сделает lstrip с доменом 'www.ru'? В общем, вы просто переписали классически, что, конечно же, в реальном коде удобнее. Но суть вопроса была в использовании функционального (!) однострочного стиле.

[Andrey Dugin]

Дмитрий Филимонов: Вы путаете функциональное программирование с обфускацией кода. Опираясь на выражение "недостаточно интересны", буду исходить исключительно из научного интереса (согласен, хорошо прокачивает мозги). Пример с reduce - чистейший однострочник и пример ФП, просто я записал его в несколько строк. Пример с map с некоторыми грязными извращениями тоже можно уложить в одну строку. Ваш нечитаемый алгоритм тоже можно назвать императивным :) Что касается 'www.ru' - во-первых, этого не было в вашем "ТЗ", во-вторых, этот пример вряд ли встретится в реальной жизни. И в качестве заключения - import this :)

[Дмитрий Филимонов]

Андрей Дугин: сильно с вами согласен и, если обратите внимание, про import this также писал. Но все же функциональное программирование не путаю с обфускацией. У вас даже переменная называется "buffer", что говорит о том, что вы явно храните состояние, изменяете его - это императивный подход. Мой нехороший пример в топике более функционален, а вот в ветке комментов выше был именно функциональный подход. Поставьте перед собой задачу написать функцию, получающую на вход список, и отдающую список, без сохранения состояния по пути.

[Andrey Dugin]

Дмитрий Филимонов: Дмитрий, в Вашем примере функция sorted() создаёт список, т.е. избыточный объект. Те же яйца, только сбоку. Не говоря уже о затратах процессорного времени на сортировку. Так в чём именно заключается преимущество Вашего "более функционального" подхода? :) Функция, получающая и отдающая список - это map. Переменная у меня называется buffer, потому что я считаю необходимым давать переменным внятные человеческие названия - это хороший тон.

[Дмитрий Филимонов]

Андрей Дугин: насчет преимуществ и "тех же яиц, только сбоку": рекомендую обзорно почитать про лямбда-исчисление (не углубляться в формализм) и про функциональную парадигму в целом (на хабре были статьи в том числе), можно обзоры языков вроде хаскеля/ерланга. Подозреваю, что вы не работали в этом направлении. Мне этот подход интересен, и я иногда "балуюсь" в коде. На практике же есть 2 огромных плюса: проще тестировать, проще распараллелить такую программу. Ну и эстетическое удовольствие, когда вместо кучи рутины (переменные какие-то, циклы, все это много места занимает, а если язык статический типа джавы, это просто полный ад), можно быстро написать маленькую функцию и коротко решить задачу.

[Andrey Dugin]

Дмитрий Филимонов: Вы уж определитесь, "написать маленькую функцию" или всё-таки однострочник :) Здесь мы говорил о Python, а не о Java/Haskell/Erlang, поэтому всё-таки стоит придерживаться pythonic-стиля. Я прекрасно Вас понимаю с точки зрения страсти к экспериментам, но всё же код должен быть легко воспринимаемым и эффективным.

[Дмитрий Филимонов]

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