На самом деле, ситуация как раз наоборот - если у вас нет большого количества подписчиков, то вам видео жмут до такой степени, что шакалов не разглядеть. И неважно платный вы пользователь или нет. Мне приходится увеличивать разрешение в разы, чтобы шакальный кодек что-то оставил в динамичных сценах. А если вы видите "Ванечка пропукался" в идеальном качестве - скорее всего его пуки смотрят десятки тысяч людей
Если б я знал будущее... Во-первых разработки взаимодействия напрямую с мозгом уже ведутся, а во-вторых прогнозировать как оно в будущем - такое себе занятие, обычно мало у кого получается зайти дальше "ну, эта штука будет в Х раз быстрее, и У раз меньше"
Понятно. Я просто стригернул на то, что иногда чтобы что-то показать в хорошем свете, то можно что-то приукрасить, а что-то приухудшить. А, вообще, оператор match хорош. Мне вообще нравятся нововведения в пайтоне, есть чем сравнивать - параллельно прогаю на перле лет 20
x = [1, 2, 3]
if isinstance(x, tuple) and len(x) == 2:
host, port = x
mode = "http"
elif isinstance(x, tuple) and len(x) == 3:
host, port, mode = x
print(host, port, mode) # не работает
match x:
case host, port:
mode = "http"
case host, port, mode:
pass
print(host, port, mode) # работает
эти 2 фрагмента не еквивалентны. А вот если убрать проверку на tuple, то работать будет. Но тогда пример у автора будет не таким красочным. Это просто зануда-мод
Я, конечно старпер и не использую match‑case, но мне кажется, что на картинке "до" и "после" не совсем эквивалент. Обмакните меня в ... и скажите, где справа проверка на tuple?
Да, чтобы что-то пофиксить, нужно долго с этим работать, знать как правильно и неправильно, а то ты при неожиданном поведении не будешь знать: это я неправильно фреймворк использую или это баг. Далее создать фикс тоже надо в стиле проекта, а для этого надо понимать какой он, а джун, мало чего в жизни повидав, вряд-ли это поймет. Дойдя то написания тестов, скорее всего скажет "да нафик оно мне надо, локально пофикшу"
Мне кажется, что шарписта (я надеюсь так корректно называть) смутили эти "трули"). На самом деле практически никто не оперирует этими понятиями. Все знают, что у базовых типов своя реакция на проверку boolean-ом, в основном очевидная. Все остальное определяется методом bool, а вот как он реализован, логично в контексте класса или нет, то уже вопрос к программисту
Я вам гарантирую, что в пайтоне (точнее, людьми, которые прогают на пайтоне, коих я знаю много или вижу их код) приведение к Boolean используется очень часто. Самый простой вариант, описанный в статье - это проверка пустой ли список (массив). По такой же логике делают и проверку объектов пустой он или нет, ну, например, объект, который собирает логи - if-ом проверяем пустой или нет (к примеру не придираться, быстро сгенерировал в голове). Другая сторона этой фичи: реализация ||= (не знаю есть ли такое в шарпе, короче, аналог += только вместо + операция "или"). Выглядит так: input_dict = input_dict or {} # определяем дикт если передали None. Это все типично для пайтона
Что там не просто? Непросто было написать такую длинную статью по информации, которую можно описать 3-4 предложениями. А так, ничего сложного нет. Приведение типов и приоритет операций есть во многих языках
Мой вариант решения проблемы: правило бойскаута «оставь место стоянки чище, чем оно было до твоего прихода». В рамках любой задачи немного рефакторишь старый код. Бывают запущенные случаи и это длится годами
На самом деле, ситуация как раз наоборот - если у вас нет большого количества подписчиков, то вам видео жмут до такой степени, что шакалов не разглядеть. И неважно платный вы пользователь или нет. Мне приходится увеличивать разрешение в разы, чтобы шакальный кодек что-то оставил в динамичных сценах. А если вы видите "Ванечка пропукался" в идеальном качестве - скорее всего его пуки смотрят десятки тысяч людей
в любом месте программы нужно знать тип и возможно часто проверять на None. Все остальное это легаси либо кривой код
ну так "str | None" читается буквально "строка или нан" - идеально
Если б я знал будущее... Во-первых разработки взаимодействия напрямую с мозгом уже ведутся, а во-вторых прогнозировать как оно в будущем - такое себе занятие, обычно мало у кого получается зайти дальше "ну, эта штука будет в Х раз быстрее, и У раз меньше"
Понятно. Я просто стригернул на то, что иногда чтобы что-то показать в хорошем свете, то можно что-то приукрасить, а что-то приухудшить. А, вообще, оператор match хорош. Мне вообще нравятся нововведения в пайтоне, есть чем сравнивать - параллельно прогаю на перле лет 20
эти 2 фрагмента не еквивалентны. А вот если убрать проверку на tuple, то работать будет. Но тогда пример у автора будет не таким красочным. Это просто зануда-мод
Я, конечно старпер и не использую match‑case, но мне кажется, что на картинке "до" и "после" не совсем эквивалент. Обмакните меня в ... и скажите, где справа проверка на tuple?
Это все так, но есть вариант транслировать прямо в мозг
Как раз будет возможность безнаказанно тырять контент с Ютуба
Да, чтобы что-то пофиксить, нужно долго с этим работать, знать как правильно и неправильно, а то ты при неожиданном поведении не будешь знать: это я неправильно фреймворк использую или это баг. Далее создать фикс тоже надо в стиле проекта, а для этого надо понимать какой он, а джун, мало чего в жизни повидав, вряд-ли это поймет. Дойдя то написания тестов, скорее всего скажет "да нафик оно мне надо, локально пофикшу"
Мне кажется, что шарписта (я надеюсь так корректно называть) смутили эти "трули"). На самом деле практически никто не оперирует этими понятиями. Все знают, что у базовых типов своя реакция на проверку boolean-ом, в основном очевидная. Все остальное определяется методом bool, а вот как он реализован, логично в контексте класса или нет, то уже вопрос к программисту
Я вам гарантирую, что в пайтоне (точнее, людьми, которые прогают на пайтоне, коих я знаю много или вижу их код) приведение к Boolean используется очень часто. Самый простой вариант, описанный в статье - это проверка пустой ли список (массив). По такой же логике делают и проверку объектов пустой он или нет, ну, например, объект, который собирает логи - if-ом проверяем пустой или нет (к примеру не придираться, быстро сгенерировал в голове). Другая сторона этой фичи: реализация ||= (не знаю есть ли такое в шарпе, короче, аналог += только вместо + операция "или"). Выглядит так: input_dict = input_dict or {} # определяем дикт если передали None. Это все типично для пайтона
Что там не просто? Непросто было написать такую длинную статью по информации, которую можно описать 3-4 предложениями. А так, ничего сложного нет. Приведение типов и приоритет операций есть во многих языках
Погулять на корпоративе и сразу уволиться - это ты классно придумал
Я недавно портировал на очки fpv. По сути объединил код самих очков и код doom-а.
https://youtu.be/bGUTo9LrM8w?si=kWMFZ19YxAJMfkZN
160к строк кода на такой небольшой набор изменений... 2) с for чувствуется влияние пайтона
Я думаю первая история правда - ибо в этом случае точка будет одна в строке - это и есть признак конца письма. А вторая котолампа, но красивая
2й скриншот правильно выдуман? После family должен же быть один перевод строки, а не 2.
Мой вариант решения проблемы: правило бойскаута «оставь место стоянки чище, чем оно было до твоего прихода». В рамках любой задачи немного рефакторишь старый код. Бывают запущенные случаи и это длится годами
Что-то я сомневаюсь, что СССР, тыривший все подряд, отвалил столько дефицитной валюты за не ракеты. Скорее всего легенда