Это понятно, но если вы не работаете с питоном постоянно, то для этого надо запустить репл и проверить, что False or 10 вернёт 10, а не True.
Такая аргументация работает в обе стороны. Если я не работаю постоянно с хаскелем (который для этого требует слома мозга), я понятия не имею что означает Bool -> Bool -> Bool.
Зависит от задач. Если нужна близость к железу (но тогда вообще какой питон?), то раст. Если нужно что-то быстро напрототипировать и есть нужные библиотеки (но это для любого языка важное условие), или, в зависимости от команды, просто умолчанию — то хаскель тот же.
И то, потому что bool является подклассом int — этот компромисс сложился исторически. Хотя я не встречал ни одной ошибки, которая бы следовала из этого.
Неочевидно, чему равен результат x or y при x ~ False — y или bool(y). Не уверен, что это можно вывести из первых принципов, поэтому это надо просто запомнить.
Равен y, оператор or возвращает операнд по его истинности. К слову, о каких принципах речь?
Можно, конечно, начать обмазываться всякими mypy, но у них довольно малая выразительная сила
Шаблоны C++ имеют чудовищную теоретическую выразительность, с их помощью можно усложнять статику до бесконечности, но вряд ли кто-то любит их читать или отлаживать.
непонятно, почему бы не взять сразу нормально типизированный язык.
Да, Python — в сравнении с Go — очень сложный язык.
Тогда язык С проще их обоих.
Скинь мне сниппет кода на Go, я перепишу его на Python. Бросаю тебе вызов ;)
в генераторах Python переменная цикла используется до заголовка цикла
Например?
Слабая типизация: к логическому типу автоматически приводится практически что угодно. Отсутствие контроля типов, порождающее трудно обнаруживаемые ошибки…
Автоматическое (неявное?) преобразование чего угодно к bool происходит только в условных выражениях. Сделать True + [] не получится. Я могу вспомнить несколько случаев неявных преобразований, причем ни одно из них не создавало проблем:
условные выражения и bool: not x, x or y
числа и bool: 5 + True
числа между собой: 10 + 10.5 + 2j
форматированные строки: f'abc: {None}'
В остальном неявные преобразования запрещены для несовместимых типов.
Подверженность людей эффекту новизны и любовь к хайпу были всегда. Казалось бы, программисты с их техническим складом ума и критическим мышлением точно понимают откуда они знают то, что знают, ан нет.
The hyperbole of The Architects Sketch may seem ridiculous, but consider how often we see software projects begin with adoption of the latest fad in architectural design, and only later discover whether or not the system requirements call for such an architecture. Design-by-buzzword is a common occurrence. t least some of this behavior within the software industry is due to a lack of understanding of why a given set of architectural constraints is useful. In other words, the reasoning behind good software architectures is not apparent to designers when those architectures are selected for reuse. https://www.ics.uci.edu/~fielding/pubs/dissertation/introduction.htm
Это было написано 20 лет назад автором REST. Позже этот термин превратится в один из самых заезженных базввордов в ИТ
Есть в этом зерно правды. Люди путаются между POST, PATCH и PUT для частичных обновлений, где последний запрещено использовать для этого, а первый предназначен для чего угодно. Аналогично с созданием — POST или PUT? Семантически можно использовать оба, но "есть нюанс". И не один. Поэтому неудивительно, что многие вендоры (vk, telegram, slack, flickr etc) используют RPC-like стиль, явно именуя адреса API.
С точки зрения API нет принципиальной разницы между POST /users.delete?user_id=1 и DELETE /users/1. Особенно если HTTP спрятан внутри языкового SDK, где POST /users превращается просто в users.create.
Состояние в "Representational state" означает состояние, в которое переходит приложение после выбора гиперссылки, и это состояние (равно как и его дальнейшие переходы) определяется представлением ресурса. Тот самый HATEOAS.
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.
REST concentrates all of the control state into the representations received in response to interactions. [...] For a browser application, this state corresponds to a "web page," including the primary representation and ancillary representations, such as in-line images, embedded applets, and style sheets.
Где исходники? Какой драйвер PostgreSQL использовался? С какими аргументами вызывался ab? Почему у Gunicorn не выставили количество воркеров в 1 для честного сравнения?
TCP and SSL are stateful, so your system is stateful whether you knew it or not
Справедливости ради, stateless протокол можно построить поверх stateful и наоборот: stateless-протокол HTTP работает поверх stateful-протокола TCP, который работает поверх stateless-протокола IP, и так далее.
Представим себе токен, который состоит из timesamp + 36 байт из urandom. Сколько триллионов токенов мы должны генерировать в день, что получить первую коллизию?
Но HTTP — это уже готовая система с архитектурой построенной в соответствии с принципами REST. И у вас есть возможность использовать готовое решение, которое описано в спецификациях, и ваш продукт смогут быстро понять те, кто знает HTTP.
Тем не менее, более широкое использование HTTP не делает систему более RESTful. Некоторые люди занимаются HTTP-фетишизмом ради того, чтобы налепить на себя "ярлык соответствия", хотя использование HTTP не является ни достаточным, ни обязательным.
Филдинг работал над REST с 1994 года параллельно c процессом стандартизации HTTP/1.0, описывая в своей работе архитектурные черты самого веба. Как архитектурный стиль, REST является более абстрактным, чем паттерны проектирования, потому что он описывает архитектуру приложение в целом (поэтому нет и никогда не будет официального RFC или ISO стандарта для REST, равно как и эталонной реализации)
Имеется в виду следующее: когда вы пишете proxy_pass в конфигурации nginx — nginx начинает как-то трактовать стандарт.
У нас нет проблем с RPC поверх HTTP, пока HTTP не нарушается значимым образом. HTTP остается в своем слое, пока приложение работает в RPC-стиле, используя GET для чтения и POST для всего остального (между прочим, POST предназначен для любых операций, которые не покрыты в рамках остальных методов)
В 2000 Фьелдинг написал абстрактно. Под «hypermedia as the engine of application» можно много чего понимать.
Много ли людей вообще знают о существовании этой диссертации, брендируя свой API вирусным термином REST? Мало кто опирается на первоисточники, обычно все заканчивается чтением коротких статей и заметок на персональных блогах которые вместо пруфлинков содержат только ИМХО их авторов.
Между прочим, вы знаете, что означает название "Representational State Transfer"?
Абсолютно ничто не мешает, кроме того факта, что HTTP как-то знает и трактует большое количество ПО в мире, а под ваш протокол придётся написать кастомные имплементации.
Такая аргументация работает в обе стороны. Если я не работаю постоянно с хаскелем (который для этого требует слома мозга), я понятия не имею что означает
Bool -> Bool -> Bool.Выбор невелик.
И то, потому что bool является подклассом int — этот компромисс сложился исторически. Хотя я не встречал ни одной ошибки, которая бы следовала из этого.
Равен y, оператор or возвращает операнд по его истинности. К слову, о каких принципах речь?
Шаблоны C++ имеют чудовищную теоретическую выразительность, с их помощью можно усложнять статику до бесконечности, но вряд ли кто-то любит их читать или отлаживать.
Какой из них и почему?
Тогда язык С проще их обоих.
Скинь мне сниппет кода на Go, я перепишу его на Python. Бросаю тебе вызов ;)
Например?
Автоматическое (неявное?) преобразование чего угодно к bool происходит только в условных выражениях. Сделать True + [] не получится. Я могу вспомнить несколько случаев неявных преобразований, причем ни одно из них не создавало проблем:
условные выражения и bool:
not x,x or yчисла и bool:
5 + Trueчисла между собой:
10 + 10.5 + 2jформатированные строки:
f'abc: {None}'В остальном неявные преобразования запрещены для несовместимых типов.
Подверженность людей эффекту новизны и любовь к хайпу были всегда. Казалось бы, программисты с их техническим складом ума и критическим мышлением точно понимают откуда они знают то, что знают, ан нет.
Это было написано 20 лет назад автором REST. Позже этот термин превратится в один из самых заезженных базввордов в ИТ
Есть в этом зерно правды. Люди путаются между POST, PATCH и PUT для частичных обновлений, где последний запрещено использовать для этого, а первый предназначен для чего угодно. Аналогично с созданием — POST или PUT? Семантически можно использовать оба, но "есть нюанс". И не один. Поэтому неудивительно, что многие вендоры (vk, telegram, slack, flickr etc) используют RPC-like стиль, явно именуя адреса API.
С точки зрения API нет принципиальной разницы между
POST /users.delete?user_id=1иDELETE /users/1. Особенно если HTTP спрятан внутри языкового SDK, гдеPOST /usersпревращается просто вusers.create.Честно говоря, я не понимаю, что значит знать полное состояние системы ;)
Состояние в "Representational state" означает состояние, в которое переходит приложение после выбора гиперссылки, и это состояние (равно как и его дальнейшие переходы) определяется представлением ресурса. Тот самый HATEOAS.
https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_1
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_3_3
Какие именно советы специфичны для REST и почему?
Поиск это ресурс, тоже. С собственной семантикой и представлением.
Совершенно верно, к тому же возможно получить следующий элемент без риска StopIteration используя
next(iterator, None)Попробуйте добавить
-k. К слову сказать, asyncpg должен заметно уделывать psycopg2 по производительностиГде исходники? Какой драйвер PostgreSQL использовался? С какими аргументами вызывался ab? Почему у Gunicorn не выставили количество воркеров в 1 для честного сравнения?
Если я не ошибаюсь, предсказатель и так всегда догадывается сам, эти макросы влияют только на упорядочивание кода (улучшают работу с кешем)
Справедливости ради, stateless протокол можно построить поверх stateful и наоборот: stateless-протокол HTTP работает поверх stateful-протокола TCP, который работает поверх stateless-протокола IP, и так далее.
Представим себе токен, который состоит из timesamp + 36 байт из urandom. Сколько триллионов токенов мы должны генерировать в день, что получить первую коллизию?
Если бы кто-то читал эти скучные тексты, мир стал бы немного лучше ;-) А так имеем дурацкие теории неофитов о CRUD в HTTP и красивом именование URI.
Тем не менее, более широкое использование HTTP не делает систему более RESTful. Некоторые люди занимаются HTTP-фетишизмом ради того, чтобы налепить на себя "ярлык соответствия", хотя использование HTTP не является ни достаточным, ни обязательным.
Филдинг работал над REST с 1994 года параллельно c процессом стандартизации HTTP/1.0, описывая в своей работе архитектурные черты самого веба. Как архитектурный стиль, REST является более абстрактным, чем паттерны проектирования, потому что он описывает архитектуру приложение в целом (поэтому нет и никогда не будет официального RFC или ISO стандарта для REST, равно как и эталонной реализации)
У нас нет проблем с RPC поверх HTTP, пока HTTP не нарушается значимым образом. HTTP остается в своем слое, пока приложение работает в RPC-стиле, используя GET для чтения и POST для всего остального (между прочим, POST предназначен для любых операций, которые не покрыты в рамках остальных методов)
Много ли людей вообще знают о существовании этой диссертации, брендируя свой API вирусным термином REST? Мало кто опирается на первоисточники, обычно все заканчивается чтением коротких статей и заметок на персональных блогах которые вместо пруфлинков содержат только ИМХО их авторов.
Между прочим, вы знаете, что означает название "Representational State Transfer"?
Как именно "большое количество ПО" должно трактовать какой-нибудь отдельно взятый HTTP API? Что конкретно имеется ввиду? Возьмем, к примеру, несколько примеров RPC-like API:
https://developer.twitter.com/en/docs/api-reference-index.html
https://api.slack.com/methods
https://www.flickr.com/services/api/
https://vk.com/dev/methods
https://core.telegram.org/methods
https://developers.google.com/youtube/v3/docs/
https://www.dropbox.com/developers/documentation/http/documentation
Здесь есть какие-то проблемы с трактовкой HTTP или еще нет?)
Не существует такого разделения. В чем именно состоит разница между REST 2000 и REST 2008?