![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Предупреждение: Мне нравится питон, но это не мешает критиковать.
В The Zen of Python есть такая мысль:
Но вы мне возразите: Ну, это же всё, кроме первого - не 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. к посту, но ты нажимаешь "Изминить" и ничего потом не происходит.
Если не ходили туда - и не ходите!!! Перескажу всё здесь, уже с учётом опыта оттуда.
Контекст:
Внимание, вопрос: Ваша реакция, как code reviewer, на следующие изменения?
Ваш коллега меняет исходную строку:
Во-первых, как видите, само изменение, взятое из реальной жизни - не совсем obvious way.
Во-вторых, в LinkedIn - никто так и не предложил вообще вариант:
Занавес.
В 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
Занавес.
no subject
Date: 2020-03-29 06:59 pm (UTC)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
Date: 2020-03-29 07:32 pm (UTC)Please, continue your line of reasoning, Captain Obvious!
Re: the first one is obviously bad in any language with immutable strings
Date: 2020-03-30 08:35 am (UTC)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
Date: 2020-03-30 09:44 am (UTC)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
Date: 2020-03-30 09:52 am (UTC)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
Date: 2020-03-30 10:00 am (UTC)