которые экземпляр (instance) класса называют объектом класса. Скажите, почему? В каких книгах так пишут?
Это калька с английского an object of a class. Теоретики иногда ещё говорят an element of a class. В большинстве случаев an instance of a class означает то же самое. В чисто практическом смысле, всегда найдутся более важные задачи, чем искать разницу между ними https://stackoverflow.com/q/2885385.
В питоне есть давняя традиция: проталкивать свежесочиненный код в стандартную библиотеку, а потом всем сообществом годами страдать и исправлять в нем баги.
Проверка по хэшам на наличие "вредоносного" ПО реализована практически на всех устройствах. Кроме собственно самой проверки это даёт массу данных о самом пользователе. Проблема лишь в том, что агрегаторы данных находятся не в Европе. Сейчас руководство многих стран старается придумать основания, чтобы под разными предлогами получить возможность присосаться к этой трубе.
Если теория всего будет формальной системой, то она окажется либо неполной, либо противоречивой. Т.е. в ней будут или утверждения с потолка или логические парадоксы. С первыми мириться проще.
В прочем, естественные науки и не пытаются описать всё на свете. Им интересны только процессы, в которых есть какие-либо закономерности или которые могут повторяться. Следствием является предсказательная сила таких наук, обусловливающая их практическую пользу. Все феномены, где нет ни каких закономерностей, остаются за рамками.
Можно вспомнить ещё JSON, который часто используется как формат обмена данными. snake_case в назначениях ключей объектов увеличивает размер передаваемых данных на ровном месте. camelCase компактнее за счёт отсутствия символов подчеркивания.
Когда этот JSON записывается в логи, а логи нужно где-то хранить, то разницу в размере видно невооружённым взглядом, просто по счетам за сторадж.
Если серьезно, используйте тот стиль, который наиболее употребим на конкретной платформе. Даже если он лично вам по каким-то причинам кажется не оптимальным. Вы же не в вакууме пишете - унификация даст гораздо больше преимуществ.
В JS у множества (Set) есть метод values(), который возвращает Последовательность (Sequency) элементов в том же порядке, в котором их туда добавляли. Фактически это преобразование объекта одного типа в объект другого. Будет-ли сравнение последовательностей эквивалентно сравнению множеств нужно было доказать прежде, чем писать код и тесты его производительности.
Лучше тут https://ru.m.wikipedia.org/wiki/Множество в разделе "Отношения между множествами". Упрощённо, два множества равны если каждый элемент одного множества так же принадлежит и другому, и наоборот.
Линейно-упорядоченным (PoSet) множество становится если для него дополнительно задать операцию, определяющую частичный порядок (partial order) его элементов (меньше-или-равно). Проще говоря - функцию сравнения двух элементов. Определение равенства самих множеств это не меняет.
Контекст менеджеры в питоне это компромисс между читабельностью и явностью (в смысле explicit is better than implicit). Используя контекст менеджер нужно постоянно держать в голове его особенности: Single Use, Reusable or Reentrant, помноженные на потокобезопасность и возможность использовать с async - пользовательский код будет выглядеть абсолютно одинаково, а поведение существенно разным.
Например:
# Где-то в другом файле
…
with filesystem.temp_umask(mask):
util.set_up_core_dir(...)
Как поведет себя этот код будучи вызванным одновременно в разных потоках с разными значениями mask?
В штатах прецедентное право. Прецедент создан, и судя по всему сознательно. Во всяком случае по реакции не похоже чтобы это была сугубо личная инициатива одного только Jakub. Теперь и другие проекты могут последовать их примеру.
Но это тоже не повод превращать патчсет в подобие референдума за конституцию, когда мейтейнерам предлагается проголосовать за десятки изменений по разным вопросам, разной степени сомнительности, фактически одним кликом?
"Спать хватит жрать". Иногда одна лишь запятая меняет смысл всего предложения. Количество строк - вопрос второстепенный. Тут важнее кого и как такие изменения могут аффектнуть в плане возможных регрессий (и не дай бг - секьюрити).
По коду выглядит как будто ребята не только сделали нужные им изменения, но ещё переписали полдрайвера ни с кем не посоветовавшись и непонятно зачем. Этакий кодинг в состоянии аффекта и не приходя в сознание.
Такие изменения всегда выглядят рискованными и обычно отправляются в корзину. Фичи должны должны быть отдельно от рефакторингов.
Откровенное тыкание пальцем в компанию звучит конечно непрофессионально и создаст отдельный медиа-прецедент. Но чисто технически, результат для всего патчсета в принципе закономерен.
Это калька с английского an object of a class. Теоретики иногда ещё говорят an element of a class. В большинстве случаев an instance of a class означает то же самое. В чисто практическом смысле, всегда найдутся более важные задачи, чем искать разницу между ними https://stackoverflow.com/q/2885385.
В питоне есть давняя традиция: проталкивать свежесочиненный код в стандартную библиотеку, а потом всем сообществом годами страдать и исправлять в нем баги.
Про @functools.cached_property есть отдельная дискуссия: https://discuss.python.org/t/finding-a-path-forward-for-functools-cached-property/23757/41. tldr; уже ни кто не сомневается, что лок на классе это баг. Но как починить - коллективый разум пока не придумал.
Проверка по хэшам на наличие "вредоносного" ПО реализована практически на всех устройствах. Кроме собственно самой проверки это даёт массу данных о самом пользователе. Проблема лишь в том, что агрегаторы данных находятся не в Европе. Сейчас руководство многих стран старается придумать основания, чтобы под разными предлогами получить возможность присосаться к этой трубе.
Если теория всего будет формальной системой, то она окажется либо неполной, либо противоречивой. Т.е. в ней будут или утверждения с потолка или логические парадоксы. С первыми мириться проще.
В прочем, естественные науки и не пытаются описать всё на свете. Им интересны только процессы, в которых есть какие-либо закономерности или которые могут повторяться. Следствием является предсказательная сила таких наук, обусловливающая их практическую пользу. Все феномены, где нет ни каких закономерностей, остаются за рамками.
Можно вспомнить ещё JSON, который часто используется как формат обмена данными. snake_case в назначениях ключей объектов увеличивает размер передаваемых данных на ровном месте. camelCase компактнее за счёт отсутствия символов подчеркивания.
Когда этот JSON записывается в логи, а логи нужно где-то хранить, то разницу в размере видно невооружённым взглядом, просто по счетам за сторадж.
Если серьезно, используйте тот стиль, который наиболее употребим на конкретной платформе. Даже если он лично вам по каким-то причинам кажется не оптимальным. Вы же не в вакууме пишете - унификация даст гораздо больше преимуществ.
Пожалуйста продолжайте, вас ни кто не ограничивает.
В JS у множества (Set) есть метод values(), который возвращает Последовательность (Sequency) элементов в том же порядке, в котором их туда добавляли. Фактически это преобразование объекта одного типа в объект другого. Будет-ли сравнение последовательностей эквивалентно сравнению множеств нужно было доказать прежде, чем писать код и тесты его производительности.
Лучше тут https://ru.m.wikipedia.org/wiki/Множество в разделе "Отношения между множествами". Упрощённо, два множества равны если каждый элемент одного множества так же принадлежит и другому, и наоборот.
Линейно-упорядоченным (PoSet) множество становится если для него дополнительно задать операцию, определяющую частичный порядок (partial order) его элементов (меньше-или-равно). Проще говоря - функцию сравнения двух элементов. Определение равенства самих множеств это не меняет.
В математическом смысле порядок элементов для Set не важен. isEqual из lodash дает правильный результат true.
У вас сравнение двух одинаковых множеств Set([1, 2]) и Set([2, 1]) даёт false. Интересно, какой была аргументация в пользу такого решения?
Контекст менеджеры в питоне это компромисс между читабельностью и явностью (в смысле explicit is better than implicit). Используя контекст менеджер нужно постоянно держать в голове его особенности: Single Use, Reusable or Reentrant, помноженные на потокобезопасность и возможность использовать с async - пользовательский код будет выглядеть абсолютно одинаково, а поведение существенно разным.
Например:
Как поведет себя этот код будучи вызванным одновременно в разных потоках с разными значениями mask?
В штатах прецедентное право. Прецедент создан, и судя по всему сознательно. Во всяком случае по реакции не похоже чтобы это была сугубо личная инициатива одного только Jakub. Теперь и другие проекты могут последовать их примеру.
Видимо плата за оригинальность детали. Лет через 50 потомки оценят такую инвестицию.
Если доказательство есть, то оно тоже должно быть в числе π - надо лишь хорошенько поискать.
Там есть прекрасные чёрные обои.
Но это тоже не повод превращать патчсет в подобие референдума за конституцию, когда мейтейнерам предлагается проголосовать за десятки изменений по разным вопросам, разной степени сомнительности, фактически одним кликом?
"Спать хватит жрать". Иногда одна лишь запятая меняет смысл всего предложения. Количество строк - вопрос второстепенный. Тут важнее кого и как такие изменения могут аффектнуть в плане возможных регрессий (и не дай бг - секьюрити).
По коду выглядит как будто ребята не только сделали нужные им изменения, но ещё переписали полдрайвера ни с кем не посоветовавшись и непонятно зачем. Этакий кодинг в состоянии аффекта и не приходя в сознание.
Такие изменения всегда выглядят рискованными и обычно отправляются в корзину. Фичи должны должны быть отдельно от рефакторингов.
Откровенное тыкание пальцем в компанию звучит конечно непрофессионально и создаст отдельный медиа-прецедент. Но чисто технически, результат для всего патчсета в принципе закономерен.
Классная статья, в смысле подбора цитат. Но ближе к середине вспомнилась ещё вот эта:
Мне кажется текст можно сократить в несколько раз без потери смысла, и тем самым сделать наш сложный мир чуточку проще, просто убрав повторы.
Есть стандарты на цветовую маркировку газовых баллонов https://en.m.wikipedia.org/wiki/Bottled_gas