arthuriantech

Просто использую Vivaldi в надежде на то, что они все-таки сделают браузер уровня Opera Presto)

Полностью согласен по поводу IDN, это надуманная отговорка. Между xn--e1afmkfd.xn--e1aybc и xn--e1afmkfd.xn--e-7tbbc разницы нет, оба выглядят одинаково бессмысленно.

Нет биндинга для Python. Я уже несколько раз натыкаюсь на MDBX (и поставил звезду за труды), в связи с чем у меня два вопроса:

• За счёт чего получили ускорение на 20%?
• С какой версией LMDB проводили последний бенчмарк?

Можно было пойти простым и эффективным путём — просто записать строки в LMDB, открыв базу данных с флагом MDB_NOSYNC. На Python это делается почти элементарно:

import lmdb

env = lmdb.open('dbenv', map_size=1024*1024*1024*32, sync=False)

for line in map(str.strip, open('file.txt').readlines()):
    if line:
        k, v = line.split(':')
        with env.begin(write=True) as txn:
            txn.put(k.encode(), v.encode())

env.sync()

Вы так говорите «табличный лукап», как будто это что-то плохое.

Как будто.
Да, поместится в L1 и будет работать быстро, увеличивая давление на кеш. Если положить на одну чашу весов два предсказуемых if, а на вторую — переход по таблице 384 байта, то я не ручаюсь, что из этого будет быстрее. Надо проверять.

Вызов __ctype_b_loc происходит до цикла. Он возвращает таблицу, по которой уже происходит лукап при каждой итерации.

На всякий случай приведу нормальный перевод The Zen of Python:

Красивое лучше, чем уродливое.
Явное лучше, чем неявное.
Простое лучше, чем сложное.
Сложное лучше, чем запутанное.
Плоское лучше, чем вложенное.
Разреженное лучше, чем плотное.
Читаемость имеет значение.
Особые случаи не настолько особые, чтобы нарушать правила.
При этом практичность важнее безупречности.
Ошибки никогда не должны замалчиваться.
Если не замалчиваются явно.
Встретив двусмысленность, отбрось искушение угадать.
Должен существовать один — и, желательно, только один — очевидный способ сделать это.
Хотя он поначалу может быть и не очевиден, если вы не голландец.
Сейчас лучше, чем никогда.
Хотя никогда зачастую лучше, чем прямо сейчас.
Если реализацию сложно объяснить — идея плоха.
Если реализацию легко объяснить — идея, возможно, хороша.
Пространства имён — отличная вещь! Давайте будем делать их больше!

Как вы обеспечиваете «No crash recovery needed. No maintenance is required.» без WAL?

Если коротко, в LMDB используется CoW, из-за чего при падении процесса отпадает необходимость в транзакционном журнале — больше не нужна "перемотка" транзакций с контрольной точки. В то же время, отсутствие WAL затрудняет реализацию репликации.

Есть неплохая бумага от автора LMDB по внутреннему устройству этой базы данных.
http://www.lmdb.tech/media/20130406-LOADays-LMDB.pdf

Читая необъяснимые истории про взаимодействие людей и техники, вспомнился "эффект Паули". Однажды у меня был случай в деревне. Ночью я подошел к маленькому ночнику, чтобы его выключить, но как только я протянул к нему руку, он потух сам. Удивлённый, я захотел включить большой свет в комнате, но после щелчка выключателя взорвалась лампа накаливания под потолком. Вот такое комбо)

Вместе с Gevent будет.

А я один на последних билдах (в пределах двух недель или месяца) испытываю достаточно частое зависание браузера в Windows?

Не один. На моей Windows 7 SP1 после обновления вивальди случилось так, что иногда он начинает жрать 100% ЦП и закрывать его приходится через диспетчер задач) Я так и не смог выяснить, что это было.

Strong typing != static typing. Это не одно и то же.

Затем, чтобы быть уверенным в исходе событий. Потому что если я пишу функцию умножающие числа я не знаю как она себя поведет при умножении килограммов на мандарины. И самое главное, я не хочу об этом думать.

Умножение килограммов на мандарины это проблема слабой типизации и неявных преобразований, а не проблема динамической типизации как таковой. В JavaScript можно сделать [] * "abcdef", но Python этого не разрешит.

https://www.infoq.com
InfoQ — статьи и новости из мира IT от профессионалов для профессионалов. Публикации рецензируются)

Или я параноик или члены консорциума W3C попросту продались лоббистам из медиакорпораций.

Не параноик. W3C был сожран WHATWG, который контроллируется конгломератом из Google, Apple, Mozilla и Microsoft. Теперь W3C больше не занимается публикацией собственных спецификаций, вся работа происходит на полях WHATWG.
https://www.opennet.ru/opennews/art.shtml?num=50764

Единый интерфейс. Реализация приложения отделена от сервиса, который оно предоставляет. То есть пользователь знает, что оно делает и как с ним взаимодействовать, но как именно оно это делает не имеет значения. При изменении приложения, интерфейс остаётся прежним, и клиентам не нужно подстраиваться.

https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_5
https://ru.wikipedia.org/wiki/REST#4._Единообразие_интерфейса
https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Развиваемому вместе с HTTP Роем Филдингом, REST'у было предназначено использовать HTTP 1.1, в качестве транспорта.

Не было. REST как архитектурный стиль не ограничивает приложение конкретным протоколом, о чем сам Филдинг писал как в диссертации, так и позже в своем блоге.

Возможные сценарии описываются термином CRUD — Create, Read, Update, Delete.

CRUD не является частью ограничений ни REST, ни HTTP.

POST используется для создания нового объекта в наборе объектов. Или более сложным языком: для создания нового подчинённого ресурса.

Включая, но не ограничиваясь. Метод POST предназначен для передачи данных на сервер с целью дальнейшей обработки — он используется для любых действий, которые не нужно стандартизировать в рамках HTTP. До RFC 5789 он был единственным легальным способом вносить частичные изменения.
https://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post
https://tools.ietf.org/html/rfc7231#section-4.3.3

Есть отличная статья, которая рассказывает о сетевой механике в Source. Затрагиваются такие проблемы, как интерполяция, лагокомпенсация, предсказание ввода. https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking:ru

Недавно — это около часа. Я бы не писал, если бы вчера не столкнулся с этим. Название не гуглилось (его ещё вспомнить надо), хотя статья на зеркале itnan.ru уже была.

Берёте любую статью и копируете ее название в поисковую систему.

Ещё раз. Это не работает для недавно удаленных статей.)

Это так не работает для статей, которые были удалены недавно. На всякий случай https://itnan.ru

Если бы она была опубликована на Хабре, то её копия сохранилась бы на бесконечном количестве зеркал Хабра, но её нигде нет.

Не подскажете хоть одно такое зеркало?)

Костная проводимость звука не зашумляет слух.
https://ru.wikipedia.org/wiki/Костная_проводимость

Она просто мешает именно вам. И кому-то еще, кто на Python тоже не пишет. Я одинаково люблю С и Python, не испытывая необходимости агитировать против утиной типизации.

И ни слова про PyPy, Cython, Numba, NumPy)

Не знаю.

Тогда я не понимаю, о чем мы говорим.

Такой софистикой можно оправдать любой распространенный миф. У нас будут проблемы с устойчивым определением того, какой именно смысл приобрел REST. Предлагаю вам ответить на простой вопрос: RESTful API — это API, который что?

Если быть честным, этот сайт описывает все ограничения REST, только расставляет неправильные акценты. К слову, на странице Resource Naming (рекомендации по именованию URI, с которых все начинают и на них же останавливаются) честно сказано, что "This is not a REST rule or constraint, but it enhances the API." Если это не rule и не constraint, тогда что ими является? Мало кто задается такими вопросами, поэтому имеем то, что имеем.

Это примерно как сказать, что какой-то паттерн проектирования не имеет стандарта, поэтому никто не вправе ограничивать нас в его трактовке. Так любая терминология может потерять смысловую нагрузку. Почему мы вообще даем имена вещам?

Длинные фрагменты кода надо заворачивать в спойлер или выкладывать на https://gist.github.com/

Это работает аналогично HTML-формам. Например, посмотрите на HAL формы (https://rwcbook.github.io/hal-forms/). Метод указывается явно или подразумевается из relation. Ссылка или указана явно, или может сформирована клиентом при использовании URI Template. Их хардкодить не нужно.

Что такое абстрактный REST?

Идеи имеют свойство развиваться и то, что было предложено в 1994 году не факт что останется актуальным в 2020.

Базис запросто может оставаться актуальным в масштабе десятилетий без значительных изменений. Парадигмы, языки программирования, шаблоны проектирования, протоколы, спецификации, API операционных систем. Язык С был языком 2017 года по версии TIOBE, хотя на тот момент ему было более сорока лет.

Во-вторых, вы не браузер разрабатываете, а веб приложение, т.е. текстовый документ, а не текстовый редактор, если брать такую аналогию.

REST предназначен для приложений с очень длительным жизненным циклом, включая веб-браузеры и весь гипертекстовый веб как таковой. Он не является применимым для большинства API (хотя многие могли бы извлечь пользу из его ограничений).

Простой пример, у меня есть клиент и несколько серверов (нод или экземпляров микросервисов), перед которыми стоит балансировщик, какую ссылку должен вернуть сервер? На балансировщик? или без ничего?

Поскольку серверная сторона контролирует ссылки, каждая ссылка может вести куда угодно. Ссылка может быть относительной и вести на тот же домен, откуда пришел ответ. Или микросервисы сами могут "перебрасывать" клиента между собой без центрального шлюза. Этот вопрос выходит за рамки REST, но в любом случае клиент ничего не знает о внутреннем устройстве сервера.

Еще вопрос, должен ли HATEOAS описывать данные, которые требуется передать, например в body?

Схематически. Например, в HTML-формах указывается информация, отвечающая за формирование ссылки и формат данных. В случае с JSON сервер может передать описание формы через JSON Schema. В целом, это достаточно сложный вопрос. Единого решения здесь нет и не предвидится.

На моей Windows 10 LTSC программа DoNotSpy не устранила регулярные вылазки системы в сеть. Особенно в играх раздражало, когда на ровном месте пинг взлетает до 300 и ты не понимаешь, что происходит. Пришлось вручную отключать "Службу оптимизации доставки" и еще несколько служб.

Совершенно верно. Филдинг указывает на это в своей диссертации.

«At no time whatsoever do the server or client software need to know or understand the meaning of a URI — they merely act as a conduit through which the creator of a resource (a human naming authority) can associate representations with the semantics identified by the URI.»
https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_2_4

Если копнуть немного глубже, можно узнать очень много нового)

Смотрите на то, как работают браузеры. HATEOAS из-за "позднего связывания" обеспечивает свободу в долговременной перспективе, позволяя клиенту и серверу развиваться независимо. Сервер имеет возможность менять ссылки, расположение страниц, их компоновку и поведение (до некоторой степени) без необходимости пересобирать клиент, что полезно для десктопных и мобильных приложений.

Тема очень обширна и на самом деле заслуживает отдельной статьи, но я по мере своих сил перескажу суть. REST ведет свою историю еще с 1994 года, когда Рой Филдинг был привлечен к работе над HTTP/1.0 и URI, став потом основным архитектором HTTP/1.1. В то время он формализовал концепции, которые использовались при проектировании веба, и затем, в 2000 году, REST в его законченном виде стал предметом докторской диссертации Филдинга.
«The name "Representational State Transfer" is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through the application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.»
https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm

Акроним HATEOAS является ничем иным, как отрывком из четвертого, центрального ограничения REST — Uniform Interface: «REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.». Практически весь современный веб, каким мы его знаем, основан на этом. Браузеры работают на гипертексте — они не содержат захардкоженных ссылок, а следуют ссылкам, которые были получены из ответов сервера, руководствуясь медиа-типами и другими метаданными. Именно из-за этого ограничения REST-клиенты похожи на браузеры.

«What needs to be done to make the REST architectural style clear on the notion that hypertext is a constraint? In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period.»
— Roy Fielding (REST APIs must be hypertext-driven)

Сейчас (на само деле давно) REST является модным ярлыком, который навешивается практически на любой HTTP API, даже если авторы понятия не имеют, что это значит.

https://www.youtube.com/watch?v=w5j2KwzzB-0
https://www.youtube.com/watch?v=pspy1H6A3FM&t=17m16s
https://roy.gbiv.com/untangled/tag/rest
https://www.infoq.com/articles/web-api-rest/
https://www.infoq.com/news/2016/07/microsoft-rest-api/
https://github.com/Microsoft/api-guidelines/pull/29
https://tyk.io/rest-never-crud/
https://stackoverflow.com/questions/19884295/soap-vs-rest-differences/19884975#19884975
https://twitter.com/fielding/status/1052976631374000128

Ресурс — это ключевая абстракция, на которой концентрируется протокол HTTP.

Природа которой не ограничена.

Транспорт: всегда HTTP. REST полностью построен на основе HTTP.

Хотя REST является формализацией концепций, заложенных в основу веба, использование HTTP не является ни достаточным, ни обязательным условием для REST.

PUT: обновить существующий ресурс

Семантически, PUT предназначен для полной замены, а не просто для обновления. Частичный PUT нарушает спецификацию HTTP. Можно смотреть на PUT как на эквивалент операции присваивания, этим, к слову, и обусловлена его идемпотентность. Для частичных обновлений подходит или POST, или PATCH.

HATEOAS является обязательной частью REST с самого начала. Ваш браузер работает на этом принципе.

Да, только generator не является функцией, возвращающей генератор. У нее и return нет вовсе.

В точности как класс, который не является функцией, возвращающей объект. У конструктора и return нет. Хотя оба являются callable и возвращают объекты.

Возвращающей генератор функцией является PyGen_NewWithQualName, вызываемая _PyEval_EvalCodeWithName вместо целевой функции при наличии флага CO_GENERATOR у целевой функции.

Не имеет никакого значения, как это реализовано на уровне C API. Интерпретатор PyPy делает по-другому, и что?

В отличие от корутин, которые полностью ориентированы на кооперативную многозадачность и требуют отдельного планировщика для выполнения, генераторы по смыслу использования очень близки к итераторам. Не удивительно, что в итоге их разделили (хотя принципиально они работают одинаково). Остальную чушь я комментировать не буду, прости великодушно)

Запись generator() по здравому смыслу (с которым не дружат создатели языка) не подразумевает ничего, кроме вызова generator().

Выражение generator() подразумевает вызов функции, которая возвращает объект генератора. Для этого не нужен отдельный синтаксис, потому что generator может быть генератором, классом, методом, функцией, любым callable-объектом. Вызов zip(iterable) может вернуть как генератор, так и итератор, но итерироваться они будут одинаково.

Да, выйти из своего фрейма в вышестоящий фрейм создателя генератор не может — можно условно говорить о том, что это уже не стэк, а разрозненные фреймы с данными

Совершенно верно, только не условно, а на самом деле. Можно выполнить next(g) поочередно из двух потоков, и в каждом случае фрейм генератора будет развернут на вершине стека соответствующего потока.