Комментарии 8
>>> log2 = {}
>>> key = 1
>>> for log2[key] in range(100):
... key *= 2
...
>>> log2[16]
4
>>> log2[1024]
10
Мне кажется за такие лайфхаки в коде надо нагоняй устраивать…
+2
НЛО прилетело и опубликовало эту надпись здесь
Выделенный вами пример положительный или отрицательный?
+1
НЛО прилетело и опубликовало эту надпись здесь
KISS замечательный принцип. Только к чему его применять к реализации библиотеки или к ее интерфейсу? На первый взгляд разработчики решили применить его только к реализации, разделив ответственность методов. Метод translate отвечает за замену, метод maketrans за преобразование. Вот и получился такой «кошмарный код».
Возникает вопрос почему внутри translate не вызвать maketrans. А в качестве аргументов методов translate использовать аргументы метода maketrans. Интерфейс бесспорно упростится.
А что ещё мы получим? Как минимум мы получим создание таблицы преобразования при каждом вызове translate. Как максимум мы получим узкое место на ровном месте, при возрастании нагрузки на проект.
ИМХО. Мне такой KISS интерфейса в стандартной библиотеке не нужен. Те кому это понадобится введут свою абстракцию.
Единственное к чему у меня есть претензия это название метода maketrans, вот оно точно не очевидное.
Возникает вопрос почему внутри translate не вызвать maketrans. А в качестве аргументов методов translate использовать аргументы метода maketrans. Интерфейс бесспорно упростится.
А что ещё мы получим? Как минимум мы получим создание таблицы преобразования при каждом вызове translate. Как максимум мы получим узкое место на ровном месте, при возрастании нагрузки на проект.
ИМХО. Мне такой KISS интерфейса в стандартной библиотеке не нужен. Те кому это понадобится введут свою абстракцию.
Единственное к чему у меня есть претензия это название метода maketrans, вот оно точно не очевидное.
+1
А как надо было? Четыре разных метода? Или четыре вида аргументов?
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Подборка @pythonetc, декабрь 2019