Python: string concatenation, The Zen of Python, and code review

[dememax]

Предупреждение: Мне нравится питон, но это не мешает критиковать.

В The Zen of Python есть такая мысль:

There should be one-- and preferably only one --obvious way to do it.
(выделение в тексте моё)

Понятное дело, я не единственный, кто обращает внимание на то, что в плане конкатенации строк (нас будут интересовать строковые переменные) в питоне - этот принцип уже давно далеко от реального положения дел; имеем:

• очевидно, + и его вариант =+;
• с помощью string.join();
• с помощью io.StringIO (см. предыдущую ссылку);
• старое доброе форматирование с помощью %;
• новое продвинутое форматирование str.format();
• или даже string.Template(template);
• formatted string literal or f-string, начиная с версии 3.6;
• уверен, существует ещё что-то, даже догадываюсь, но это выходит за рамки этого поста...

Но вы мне возразите: Ну, это же всё, кроме первого - не obvious way!
И я соглашусь с вами, но только не для текущего состояния дел!!! Текст по ссылке во втором пункте - авторитетно закрепляет это!

И я в этом убедился, спросив в группе "Python Professionals" на LinkedIn про изменения в коде с точки зрения code reviewer'а:

https://www.linkedin.com/feed/update/urn:li:activity:6649683558900334592

В LinkedIn отвратительные возможности по форматированию. Их просто НЕТ!
Как только пользователи не извращаются: https://www.youtube.com/watch?v=q08twTII90w
Только представьте, они с помощью специальных символов юникода генерируют текст в нужном формате: https://www.linkedin-makeover.com/linkedin-text-formatter/
И исправить пост потом невозможно! Я хотел пояснить контекст поста, уточнить исходные условия в P.S. к посту, но ты нажимаешь "Изминить" и ничего потом не происходит.

Если не ходили туда - и не ходите!!! Перескажу всё здесь, уже с учётом опыта оттуда.

Контекст:

• некий проект заявляет python >= 3.5;
• я намеренно использую вымышленные короткие имена переменных, в реальном коде - они носят вполне осмысленные имена не в один символ;
• performance isn't a problem (если же вам интересна гипотетическая производительность - https://dememax.dreamwidth.org/161418.html);
• переменные - точно являются стоковыми значениями;
• приведённая строчка - лишь часть коммита по изменению функционала (примерно 55 additions, 35 deletions).

Внимание, вопрос: Ваша реакция, как code reviewer, на следующие изменения?

Ваш коллега меняет исходную строку:

    return "%s%s%s" % (a, b, c)

на следующий код:

    return '{}{}{}'.format(a, b, c)

Во-первых, как видите, само изменение, взятое из реальной жизни - не совсем obvious way.
Во-вторых, в LinkedIn - никто так и не предложил вообще вариант:

    return a+b+c

Занавес.

Comments

[juan_gandhi]

Упадок культуры. Что тут дискутировать-то, тоска...

[sassa_nf]

> это же всё, кроме первого - не obvious way!

ahem... but the first one is obviously bad in any language with immutable strings.

Re: the first one is obviously bad in any language with immutable strings

[dememax]

(I like this game!)

Please, continue your line of reasoning, Captain Obvious!

Re: the first one is obviously bad in any language with immutable strings

[sassa_nf]

:) I would go for a+b+c, but '%s%s%s' % (a, b, c) is among the obvious ones - it is nicer than +, because it hints you what the end result is going to look like.

Most of the time the simplicity of expression is worth more than any hypothetical performance gain.

Re: the first one is obviously bad in any language with immutable strings

[dememax]

Stop! I cannot agree more... But!

It's not the continuation of your message in the initial comment of this thread!

What's a game!

Re: the first one is obviously bad in any language with immutable strings

[sassa_nf]

Probably not.

When I posted that comment I recalled a piece of Ruby code where replacing "+" for the equivalent of io.StringIO gave 1000x improvement. (Compressing / uncompressing document attachments in emails)

But then I thought some more about that, and you can treat the continuation of this thread as me retracting that claim. Most of the time + or % vs something more complex just doesn't matter.

Re: then I thought some more about that

[dememax]

Thanks! I realy appreciate your comments.

[alll]

Это у Гвидо небось просвечивал комплекс по отношению к Ларри - тот типа афоризмил "There's more than one way to do it".

Re: у Гвидо ...комплекс по отношению к Ларри

[dememax]

Я не разбирался в истории их взаимоотношений в этом смысле, но в следующем посте я так и назвал этот питоновский принцип - "анти-перл".

[dimonb]

a+b+c — больше копирований в памяти

Коллега правильно сделал

Re: a+b+c — больше копирований в памяти

[dememax]

Во-первых, из контекста:

> performance isn't a problem

Во-вторых, по ссылке из той же строчки:

> $ python -m timeit -s 'a,b,c = "a", "b", "d"' 'a + b + c'
10000000 loops, best of 3: 0.0818 usec per loop
$ python -m timeit -s 'a,b,c = "a", "b", "d"' '"{}{}{}".format(a, b, c)'
1000000 loops, best of 3: 0.286 usec per loop

Не знаю, из-за копирований или ещё чего (собственно, всё равно из-за чего) - конечный вариант с этой точки зрения хуже, чем a+b+c.

[sassa_nf]

> Ваша реакция, как code reviewer...
> Ваш коллега меняет...

"Someone has a lot of time on their hands. I'll spend more time discussing the change than the change is worth."

Re: discussing the change than the change is worth

[dememax]

We are humans.
I've added P.S. to my next post which explains a little why I bother.

Re: discussing the change than the change is worth

[sassa_nf]

I wouldn't mind the existence of a discussion. I think reviewing coding practices and habits is healthy.

But the answer to the question what I would have thought as code reviewer of a change like that, is "Someone has a lot of time on their hands" :)