Это, видимо, если считать только ответы «Да, возможно» и «Нет, невозможно». Если ты на каждый ответ «Да, возможно» привёл нужный код, то, я бы сказал, твои результаты значительно лучше случайных.
Решил только 5 и 6. До сравнения set'ов не додумался, count пустой строки - новое для меня (надо посмотреть как он работает вообще), разворачивание аргумента из двойного листа не допер (посыпаю голову пеплом), и со строками в последнем тоже протупил.
Всего реальных wat (~ косяк заложенный сознательно в яп) только одна штука, это all([]). Остальное примерно три баги - древний c «+=» и два с численными типами.
Всего реальных wat (~ косяк заложенный сознательно в яп) только одна штука, это all([]).
Это не баг, а глубоко продуманное решение, как и то, что any([]) == False. потому что Гвидо не прогуливал в универе математику, в отличие от некоторых. В алгебре для любой ограниченной решётки выполняется ⋁∅=0 и ⋀∅=1. По-другому нельзя, т. к. это поломало бы всё на свете. И с житейской точки зрения в этом есть ясный смысл: список из 0 условий считается выполненным. Когда ты из списка Todo вычёркиваешь последний пункт, он же становится выполненным полностью. А если б нет, как вообще жить?
>>> todo = [Task("сходить на работу", Task("сходить в магазин"), Task("вынести мусор")]
Когда все дела выполнены:
>>> [task.is_completed() for task in todo]
[True, True, True]
>>> all(task.is_completed() for task in todo)
True
Список дел на субботу:
>>> todo = [] # день отдыха
>>> [task.is_completed() for task in todo]
[]
>>> all(task.is_completed() for task in todo)
True
Или ты хочешь, чтобы Питон вернул False, и пустой список дел было невозможно выполнить? Или хочешь всё время проверять пустой список с помощью len() как особый случай? Ты понимаешь, что твоя логика противоречит математической логике?
В документации есть код, чудесно иллюстрирующий дуальность операций all() и any(). Помедитируй над этим. И над тем, почему ⋃∅=∅, но ⋂∅=U (универсальное множество). Дальше думай сам, не могу тратить на тебя весь выходной.
В The undocumented converse implication operator тоже всё логично. Посмотри возведение в степень что возвращает. Попросту True и False это define True 1, define False 0 в интерпретаторе. Там вполне логичное поведение. Как и в Mixing numerical types. Тут играют с максимальной точностью Double.
Хотя хз, надо хорошо думать, в какую сторону приводить, к большей или меньшей точности. Интересно, а как Julia себя ведет, там вроде в документации хорошо расписано что к чему и почему приводится...
У питона простая внутренняя логика, которая объясняет все сабжевые «странности». У перла - 10000 особых случаев, которые невозможно запомнить и невозможно понять.