Б
См. выше - .format() нужен не только для **kwargs, он еще нужен для сложных выражений или вызовов, которые не очень хорошо смотрятся внутри f-строки
Имхо лучше такое выносить в переменные
Size: a a a
2021 January 15
D
Зачем плодить ненужные переменные?
D
Дело в том что .format() с выражениями уже есть. Получается вытаскивать его аргументы в ненужные переменные.
Б
Зачем плодить ненужные переменные?
Ты ведь сам говоришь, что выражения сложные и плохо смотрятся внутри
D
В .format() они не плохо смотрятся. каждое на отдельной строке, строки разделены запятыми
D
А в f-строке так визуально не отформатировать
D
.format(
a.b(),
c.d()
)
a.b(),
c.d()
)
D
только подлиннее
Б
Я просто не совсем понимаю, что плохого будет, если вынести эти выражения в переменные, если хочется использовать f-строки
Б
+ легче читать будет имхо
D
Да вроде .format() неплохо читается многострочный
D
Ладно, не важно.
2021 January 16
D
Если тебе нужны кварги с конкретными именами, то их не нужно использовать через kwargs, а явно перечислить в аргументах функции.
Приведи близкий к твоей задаче пример. Или саму задачу, если она не секретная.
Приведи близкий к твоей задаче пример. Или саму задачу, если она не секретная.
.format(**kwargs) это мини-Jinja самый простейший вид шаблонов. Правда в большей степени для текста а не для html.
D
В принципе внутри Jinja есть нечто подобное Markup.format()
D
Только это внешние зависимости которые не всегда нужны.
D
Однако тут f-strings просто пролетает мимо.
D
Но есть и другие виды форматирования, когда аргумент подстановки сложный. Тут тоже f-strings не оптимален.
D
Это печально.
D
Пример Боброния неплох, спасибо.
MV
Виноват