Именно name, потому что это параметр данной функции. Если бы было __name__, то параметр name бы никак не использовался, и в нем не было бы никакого смысла. __name__ передается этой функции в файле main.py, вот так: logger = app_logger.get_logger(__name__).
Отчасти, отследить строку с забытой перед ней f помогает подсветка фигурных скобок, по крайней мере в Visual Studio Code с расширением Python такое наблюдаю. Конечно, это не так заметно, по сравнению с сообщениями линтера.
В одной статье читал, что str.format якобы плох в том случае, когда в нем используются именованные аргументы, а именно в этой: https://realpython.com/python-f-strings/
Я бы не сказал, что "здорово снижают". Со временем, если чаще ими пользоваться, то они воспринимаются лучше, чем поначалу. В них же еще можно использовать перенос строки, например, отделять с помощью него ту часть, которая до for.
squared_evens = [n**2
for n in range(10)
if n % 2 == 0]
Тоже видел подобный перевод. Но, по-моему, он вносит некоторую путаницу – в Python этот термин уже используется для другой штуки, о которой, кстати, говорится в 10 пункте этой статьи. Т. е., было бы так:
def custom_splitter(file, delimiter, remove_delimiters):
counter = 0
segment = ''
del_length = len(delimiter)
while char := file.read(1):
segment += char
counter += 1
if counter % del_length == 0 and segment.endswith(delimiter):
yield segment[:-del_length] if remove_delimiters else segment
segment = ''
counter = 0
with open('text.txt', encoding='utf-8') as file:
for segment in custom_splitter(file, '<...>', True):
print('-'*20)
print(segment)
Хотя возможно, что с точки зрения производительности лучше было бы хранить и обновлять строку из последних символов, количество которых равно длине разделителя, и определять конец сегмента по ней, вместо str.endswith.
В статье тоже геттеры, сеттеры, мутации в index.js модуля импортируются, если не ошибаюсь. Да, сканирования и автоматического импорта нет, модули импортируются вручную, но как альтернативный вариант, без сканирования — разве не имеет право на жизнь? Может быть автору оригинала нравится именно вручную?
Не говорите за всех. Там, где есть устоявшийся русскоязычный термин – следует его и использовать, а не создавать новую терминологию.
Пропустил еще одно место, где фигурирует данный фрагмент. Да, в параграфе "Логгер" действительно должно быть
__name__
.Именно
name
, потому что это параметр данной функции. Если бы было__name__
, то параметр name бы никак не использовался, и в нем не было бы никакого смысла.__name__
передается этой функции в файлеmain.py
, вот так:logger = app_logger.get_logger(__name__)
.Отчасти, отследить строку с забытой перед ней f помогает подсветка фигурных скобок, по крайней мере в Visual Studio Code с расширением Python такое наблюдаю. Конечно, это не так заметно, по сравнению с сообщениями линтера.
В одной статье читал, что str.format якобы плох в том случае, когда в нем используются именованные аргументы, а именно в этой: https://realpython.com/python-f-strings/
Пример без if — умно. Для примера в статье, вероятно, лучше подойдет словарь?
Как раз подобное имел в виду.
Да, генераторы коллекций – путаницы действительно меньше.
С другой стороны, теоретически может быть путаница с вещами наподобие этой:
Он визуально стал похож на for, но вряд ли потерял преимущество в производительности, которое вы упомянули. Насчет отладки согласен.
Похоже, вы правы. В десятом пункте действительно выполняется итерация по итератору строк файла через вызов метода
__next__
, если я корректно выразился.Наткнулся на такую, вроде бы неплохую, статью https://opensource.com/article/18/3/loop-better-deeper-look-iteration-python на эту тему.
Конечно, если использовать тернарные выражения и более одного цикла / вложенные включения – тогда действительно прощай читабельность.
Я бы не сказал, что "здорово снижают". Со временем, если чаще ими пользоваться, то они воспринимаются лучше, чем поначалу. В них же еще можно использовать перенос строки, например, отделять с помощью него ту часть, которая до for.
Да, вроде неплохая статья. Как-то читал в документации про форматирование – тяжело все запомнить.
Тоже видел подобный перевод. Но, по-моему, он вносит некоторую путаницу – в Python этот термин уже используется для другой штуки, о которой, кстати, говорится в 10 пункте этой статьи. Т. е., было бы так:
...
Тоже вариант, который, вероятно, лучше моего.
Написал тот, о котором упоминал:
Написал такое:
Хотя возможно, что с точки зрения производительности лучше было бы хранить и обновлять строку из последних символов, количество которых равно длине разделителя, и определять конец сегмента по ней, вместо
str.endswith
.