Всё нормально с OpenAPI, если его достаточно глубоко встроить в проект. К примеру, рабочие валидаторы/извлечение данных из запроса задаются с помощью OpenAPI, а схема ответов всегда автоматически проверяется в тестах. Без достаточной автоматизации это всё не работает.
Нормальные вопросы для собеседования. Но лучше сначала показывать майндфак, а потом предлагать объяснить/пофиксить. За незнание заранее минус не ставить.
Аналогичный пример для числа > 256 сработает ожидаемо
А вот PyPy выдаст True вместо False.
Про LOAD_CONST я бы добавил пояснение, что за массив констант такой. Его можно глянуть в test.__code__.co_consts.
Про метод против функции, как-то не проясняется сам механизм, что дескрипторы используются только при заглядывании в свойства класса, если в экземпляре свойства с таким именем не оказалось. Если дескриптор читается, то вызывается его метод __get__, а такой метод есть у любой функции. Можно делать любопытные вещи:
>>> f = lambda self: self + 1
>>> m = f.__get__(6)
>>> m
<bound method <lambda> of 6>
>>> m()
7
То есть, чтобы исправить пример нужно написать
self.b = (lambda self: None).__get__(self)
тогда функция b привяжется к self и станет методом, в точности как a.
Возможно инструкций используется гораздо больше, например в Gentoo с -march=native. Предкомпилированные дистрибутивы собираются с максимально совместимыми наборами инструкций.
Я бы ещё посоветовал вместо очистки по окончанию теста делать очистку перед тестом. Во-первых, если тест упал можно подсмотреть что в БД. Во-вторых, если процесс с тестами был убит с помощью сигналов, например если завис, то при следующем запуске не будет падения из-за нестёртых данных.
И ещё, очень полезно рандомизировать все сиквенсы перед тестами, каждый id будет начинаться со случайного большого числа, и в тестах исчезнет риск сравнить id апельсинов c id крокодилов.
Получается светофоры для поездов в Factorio сделаны реалистично, там тоже есть красные, зелёные и жёлтые сигналы, и работает всё как описано в статье. И перегоны от светофора до светофора, можно сделать километровый, а можно длиной в пару вагонов, и заехать в него сможет только один поезд.
Смею предположить, что основной use case для такого экранирования — это всё-таки пользовательские данные, которые в шаблон попадают через json.encode. В json нет арифметических операторов, поэтому всегда <!--, -->, <script, </script> будет внутри строк. Более того, json это не джаваскрипт, и чтобы стало совсем правильно, нужно делать var x = JSON.parse("..."), у которого единственный аргумент сплошная строка. В остальных случаях, когда код пишется непосредственно разработчиком, спецификация вполне резонно предлагает избегать сомнительных конструкций.
Спасибо за статью, привычка полагаться на htmlescape действительно может подвести. Но решение вызывает определённые сомнения: почему бы просто не экранировать сразу в шаблонизаторе как рекомендует стандарт, выдавая нативный тег script? Ограничиваясь по сути имплементацией темплейттега в джанге.
По правде говоря, не припомню Меркатора в школьных учебниках. Вот таких карт (к сожалению на глаз назвать проекцию не могу) было превалирующее множество.
Всё нормально с OpenAPI, если его достаточно глубоко встроить в проект. К примеру, рабочие валидаторы/извлечение данных из запроса задаются с помощью OpenAPI, а схема ответов всегда автоматически проверяется в тестах. Без достаточной автоматизации это всё не работает.
Всё ждал когда же упомянут monkeypatching или какие-то модули, закрывающие собой стандартные, но не дождался.
Нормальные вопросы для собеседования. Но лучше сначала показывать майндфак, а потом предлагать объяснить/пофиксить. За незнание заранее минус не ставить.
А вот PyPy выдаст True вместо False.
Про
LOAD_CONSTя бы добавил пояснение, что за массив констант такой. Его можно глянуть вtest.__code__.co_consts.Про метод против функции, как-то не проясняется сам механизм, что дескрипторы используются только при заглядывании в свойства класса, если в экземпляре свойства с таким именем не оказалось. Если дескриптор читается, то вызывается его метод
__get__, а такой метод есть у любой функции. Можно делать любопытные вещи:То есть, чтобы исправить пример нужно написать
тогда функция
bпривяжется к self и станет методом, в точности какa.Можно считать что это такая монорепа для множества проектов.
Возможно инструкций используется гораздо больше, например в Gentoo с
-march=native. Предкомпилированные дистрибутивы собираются с максимально совместимыми наборами инструкций.И ещё, очень полезно рандомизировать все сиквенсы перед тестами, каждый id будет начинаться со случайного большого числа, и в тестах исчезнет риск сравнить id апельсинов c id крокодилов.
Смею предположить, что основной use case для такого экранирования — это всё-таки пользовательские данные, которые в шаблон попадают через
json.encode. В json нет арифметических операторов, поэтому всегда<!--,-->,<script,</script>будет внутри строк. Более того, json это не джаваскрипт, и чтобы стало совсем правильно, нужно делатьvar x = JSON.parse("..."), у которого единственный аргумент сплошная строка. В остальных случаях, когда код пишется непосредственно разработчиком, спецификация вполне резонно предлагает избегать сомнительных конструкций.