>> Это не умножение строки на число. Это помножение строки числом. :)
> Ну так * - оператор умножения или "помножения"? :)
>> Если чего-то взять пять раз, то получится пять чеготов.
> А объект на число в ГБ умножить можно? Что получится на выходе?
> А если массив умножить - будет 5 массивов, или весь массив,
> умноженный на 5? А если в массиве еще массивы? А если
> число на объект? Или число на строку? Oops.f = lambda a: a
f(5)
5
f * 5
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for *: 'function' and 'int'
d = {'a': 5, 'b': [0,4,{'a':99}]}
d * 5
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for *: 'dict' and 'int'
l = list(d.items())
l
[('a', 5), ('b', [0, 4, {'a': 99}])]
l * 5
[('a', 5), ('b', [0, 4, {'a': 99}]), ('a', 5), ('b', [0, 4, {'a': 99}]), ('a', 5), ('b', [0, 4, {'a': 99}]), ('a', 5), ('b', [0, 4, {'a': 99}]), ('a', 5), ('b', [0, 4, {'a': 99}])]
>> Это самое логчное, что ожидаешь увидеть, исходя из детсадовского курса
> Obvious fix. А когда вырастаешь из детсада - то узнаёшь про строгие
> и нестрогие типизации, приведение типов, и много чего еще.
Красивое лучше, чем уродливое.
Явное лучше, чем неявное.
Простое лучше, чем сложное.
Сложное лучше, чем запутанное.
Плоское лучше, чем вложенное.
Разреженное лучше, чем плотное.
Читаемость имеет значение.
Особые случаи не настолько особые, чтобы нарушать правила.
При этом практичность важнее безупречности.
Ошибки никогда не должны замалчиваться.
Если не замалчиваются явно.
Встретив двусмысленность, отбрось искушение угадать.
Должен существовать один — и, желательно, только один — очевидный способ сделать это.
Хотя он поначалу может быть и не очевиден, если вы не голландец.
Сейчас лучше, чем никогда.
Хотя никогда зачастую лучше, чем прямо сейчас.
Если реализацию сложно объяснить — идея плоха.
Если реализацию легко объяснить — идея, возможно, хороша.
Пространства имён — отличная штука! Будем делать их побольше!
