goto definition показывает сгенерированный класс, который читать невозможно
Зачем читать сгенерированный код? К протобуфам можно и нужно относиться как к POD.
либо проблемы с межьязыкоровой совместимостью когда proto создается динамически по исходникам
Зачем proto генерить по исходникам? По исходникам чего, вообще, и как вы это себе представляете? Не по исходникам же типов потому что типы генерируют сами протобуфы. Потом, откуда будут браться номера полей? Или при удалении поля едет совместимость?
Нет, .proto всегда single source of truth, это из него все генерятся. Да и независимо от того откуда взялся.proto, откуда взяться проблемам межьязыковой совместимости если именно и хон и решает?
По мне так это имеет смысл уже ради одной только возможности не связываться с инфраструктурой npm вне разрабатываемого кода. То есть с тем что во фронтэнд проект надёргается куча непроверенного кода из интернета ещё может и можно смириться, но запускать таковой код под своим пользователем чтобы это собирать и линтить - дикость.
Ключевая проблема лоттократии — это выбор источника случайных чисел, который не поддавался бы влиянию людей, заинтересованных в определённых результатах выборов
А что, неужели нет никаких достаточно легко наблюдаемых, точно измеримых, плохо прогнозируемых и не поддающихся влиянию человека и фальсификации природных явлений, чтобы городить какое-то сжигание конвертов? Очевидно что это макроявления, скорее всего астрономические. Не знаю, пусть условное число протуберанцев на солнце за какой-то период или конфигурации вихрей на Юпитере.
Не могу одного понять: если вы считаете это правило ничем не обоснованной IT муштрой, и не было утилиты которая его проверяет и энфорсит, зачем было нужно её писать вместо того чтобы правило игнорировать и саботировать?
DNS туннель проще, быстрее и работает почти всегда. А так в эпоху районных локалок (локалка была общая у нескольких провайдеров с весьма разной вкусности тарифами) через что только не тунеллировали IP - и через ICQ (доступ к которой не ограничивался), и через файлы на ftp, и через лички на форумах. В нынешнее время, увы, это снова становится актуальным.
"Хотим искать кратчайшие в евклидовой метрике пути в лабиринте на квадратной сетке где можно ходить на 8 соседей, при этом погрешности недопустимы. Для этого берём любой алгоритм поиска кратчайшего пути, длину представляем в виде суммы целой части с частью содержащей квадратный корень в качестве множителя, учимся сравнивать представленные таким образом числа - для этого группируем целые части и части с корнями и сравниваем их квадраты." Это всё содержание статьи. Какой смысл несет остальная псевдоматематически-формальная вода?
Нет, не странно. Во-первых, тесты не обязательно запускать на железке. Нормальный код абстрагирован от io как минимум в целях переносимости, и можно мокнув оное протестировать всю логику прошивки локально. Если нет, то всё равно всегда есть части кода которые можно тестировать обособленно. Во-вторых, микроконтроллеры это уже давно не avrки с 512 байт памяти, уж функция с простынёй ассертов туда влезет всегда.
Любая инвертированная логика неинтуитивна, а for..else скорее всего задумывался для прямолинейной логики поиска, которая выглядит вполне логично:
for x in iterable:
if predicate(x):
break
else:
raise NotFoundException()
# work with x
И я бы даже предпочёл её более современному функциональному коду, который в питоне получается отвратителен:
if (x := next(filter(predicate, iterable)), None) is None:
raise NotFoundException()
if (x := next((i for i in iterable if predicate(i)), None) is None:
raise NotFoundException()
try:
x = next(filter(predicate, iterable))
except StopIteration:
raise NotFoundException()
from more_itertools import first_true # лучше, но нужен внешний модуль
if (x := first_true(iterable, pred=predicate)) is None:
raise NotFoundException()
Сомнительная фича, как минимум требующая намного больше логики для правильной реализации. Например, что если изображение с высоким качеством уже закэшировано, зачем качать заново низкокачественное.
Нет, ценность именно (на самом деле только) в коммьюнити. В git хостинг репозиториев ценности не имеет, потому что git распределённый и любой клон сам себе хостинг, а равнозначные зеркала тиражируются элементарно, даже при полной потере сетевой связности. Ценность GH в том что только туда можно отправить PR который будет принят в основную ветку, только туда можно открыть issue который будет обработан и свой проект залитый туда будет иметь максимальную видимость среди пользователей и контрибуторов. Повторить это в изолированном местячковом сервисе невозможно физически.
Нет никакого смысла стремиться к тому чтобы код был похож на код стандартных библиотек Python, уж скорее есть смысл в обратном. Удобно и правильно писать на полноценном идиоматичном C++, а сишная прослойка между ним и питоновским API будет очень тонкой и ограниченной конвертацией аргументов и возвращаемых значений между PyObject и плюсовыми типами. В случае же когда код модуля вынужден оперировать PyObject'ами, я вообще считаю преступлением писать руками простыни Py_INC/DEC/XDECREF'ов вместо того чтобы обернуть PyObject в плюсовый класс с поддержкой move semantics и явной передачей владения/заимствованием и писать на нем лаконичный, понятный и безопасный код.
Это только от безысходности, когда системного пакетного менеджера нет. А когда он есть и из него ставятся и система, и приложения, и инструменты, и библиотеки всех языков сразу (что особенно важно в местах их пересечения, например питоновских биндингов к плюсовым библиотекам), нет никакого смысла иметь ещё один, ограниченный и вдобавок привязанный к какой-то IDE, когда у меня, во-вторых, другая IDE, а во-первых, IDE для сборки вообще не нужна. Сборка это `git clone && cmake|meson && ninja` плюс упомянутая установка зависимостей.
Ставятся из системного репозитория как любой другой софт.
Зачем читать сгенерированный код? К протобуфам можно и нужно относиться как к POD.
Зачем proto генерить по исходникам? По исходникам чего, вообще, и как вы это себе представляете? Не по исходникам же типов потому что типы генерируют сами протобуфы. Потом, откуда будут браться номера полей? Или при удалении поля едет совместимость?
Нет, .proto всегда single source of truth, это из него все генерятся. Да и независимо от того откуда взялся.proto, откуда взяться проблемам межьязыковой совместимости если именно и хон и решает?
По мне так это имеет смысл уже ради одной только возможности не связываться с инфраструктурой npm вне разрабатываемого кода. То есть с тем что во фронтэнд проект надёргается куча непроверенного кода из интернета ещё может и можно смириться, но запускать таковой код под своим пользователем чтобы это собирать и линтить - дикость.
А что, неужели нет никаких достаточно легко наблюдаемых, точно измеримых, плохо прогнозируемых и не поддающихся влиянию человека и фальсификации природных явлений, чтобы городить какое-то сжигание конвертов? Очевидно что это макроявления, скорее всего астрономические. Не знаю, пусть условное число протуберанцев на солнце за какой-то период или конфигурации вихрей на Юпитере.
Не могу одного понять: если вы считаете это правило ничем не обоснованной IT муштрой, и не было утилиты которая его проверяет и энфорсит, зачем было нужно её писать вместо того чтобы правило игнорировать и саботировать?
DNS туннель проще, быстрее и работает почти всегда. А так в эпоху районных локалок (локалка была общая у нескольких провайдеров с весьма разной вкусности тарифами) через что только не тунеллировали IP - и через ICQ (доступ к которой не ограничивался), и через файлы на ftp, и через лички на форумах. В нынешнее время, увы, это снова становится актуальным.
Зачем такая сложность? Можно
git diff HEAD^, а вообще простоgit show"Хотим искать кратчайшие в евклидовой метрике пути в лабиринте на квадратной сетке где можно ходить на 8 соседей, при этом погрешности недопустимы. Для этого берём любой алгоритм поиска кратчайшего пути, длину представляем в виде суммы целой части с частью содержащей квадратный корень в качестве множителя, учимся сравнивать представленные таким образом числа - для этого группируем целые части и части с корнями и сравниваем их квадраты." Это всё содержание статьи. Какой смысл несет остальная псевдоматематически-формальная вода?
Просто не читайте "блоги компаний".
Нет, не странно. Во-первых, тесты не обязательно запускать на железке. Нормальный код абстрагирован от io как минимум в целях переносимости, и можно мокнув оное протестировать всю логику прошивки локально. Если нет, то всё равно всегда есть части кода которые можно тестировать обособленно. Во-вторых, микроконтроллеры это уже давно не avrки с 512 байт памяти, уж функция с простынёй ассертов туда влезет всегда.
Любая инвертированная логика неинтуитивна, а for..else скорее всего задумывался для прямолинейной логики поиска, которая выглядит вполне логично:
И я бы даже предпочёл её более современному функциональному коду, который в питоне получается отвратителен:
Потому что assignment expressions появились ещё в 3.8?
В какой-то момент игрался с termux, запустил там vim и понял что он на порядок удобнее штатных контролов для редактирования текста.
Сомнительная фича, как минимум требующая намного больше логики для правильной реализации. Например, что если изображение с высоким качеством уже закэшировано, зачем качать заново низкокачественное.
Совсем не обязательно. Достаточно атаковать расшаренную с кем-то страницу.
Комьюнити нельзя создать, оно само возникает вокруг проектов.
Нет, ценность именно (на самом деле только) в коммьюнити. В git хостинг репозиториев ценности не имеет, потому что git распределённый и любой клон сам себе хостинг, а равнозначные зеркала тиражируются элементарно, даже при полной потере сетевой связности. Ценность GH в том что только туда можно отправить PR который будет принят в основную ветку, только туда можно открыть issue который будет обработан и свой проект залитый туда будет иметь максимальную видимость среди пользователей и контрибуторов. Повторить это в изолированном местячковом сервисе невозможно физически.
Нет никакого смысла стремиться к тому чтобы код был похож на код стандартных библиотек Python, уж скорее есть смысл в обратном. Удобно и правильно писать на полноценном идиоматичном C++, а сишная прослойка между ним и питоновским API будет очень тонкой и ограниченной конвертацией аргументов и возвращаемых значений между PyObject и плюсовыми типами. В случае же когда код модуля вынужден оперировать PyObject'ами, я вообще считаю преступлением писать руками простыни Py_INC/DEC/XDECREF'ов вместо того чтобы обернуть PyObject в плюсовый класс с поддержкой move semantics и явной передачей владения/заимствованием и писать на нем лаконичный, понятный и безопасный код.
Это только от безысходности, когда системного пакетного менеджера нет. А когда он есть и из него ставятся и система, и приложения, и инструменты, и библиотеки всех языков сразу (что особенно важно в местах их пересечения, например питоновских биндингов к плюсовым библиотекам), нет никакого смысла иметь ещё один, ограниченный и вдобавок привязанный к какой-то IDE, когда у меня, во-вторых, другая IDE, а во-первых, IDE для сборки вообще не нужна. Сборка это `git clone && cmake|meson && ninja` плюс упомянутая установка зависимостей.
Это зависит от репозитория. Где-то они не разделяются, где-то нужно добавить -devel суффиксы.