Ну про закрыть канал писателем - это очевидно же.... но только если пишет один....
В случае многих писателей можно смело утверждать, что эти писатели тоже где-то создаются и кем-то ожидаются. Соответственно, этот кто-то ждёт пока отработают все писатели и закрывает канал, в который отправлялись данные.
Не знаю зачем я тут вклиниваюсь, но всё же вклинюсь. Таки согласен. Не понимаю, почему людей так интересуют именно декораторы в питоне, ведь этот паттерн реализуем везде, где можно объявлять функции высшего порядка. Всё то же самое можно делать и в каком-нибудь условном JS, только без синтаксического сахара.
Когда думаешьо декораторе просто как о функции, принимающей в качестве аргумента другую функцию, вся магия куда-то улетучивается.
Что не так? Автор этого кода явно прописал, что происходит только обработка значений true и false. Если там, например, null или, не дай бог, пустой массив (мне доводилось видеть всякое), ничего не произойдёт.
совсем не понимаю, что в этих запросах может быть сложного
Вот эта ремарка вызывает ощущение, будто автор очень мало и очень поверхностно поработал как с ORM, так и с SQL. Хотя сама статья, если честно, вызвала прямо противоположные чувства.
Можно сколько угодно спорить о том, какой подход более "трушный" - замаппить данные самостоятельно или использовать ORM. Но вот сомневаться в сложности как одного, так и второго метода - как минимум подозрительно.
Самое первое, что приходит мне на ум, когда я слышу о том, что писать запросы (на чистом SQL или через ORM - не важно) это просто - это попросить автора этих слов разобрать порядок выполнение какого-нибудь более-менее сложного запроса. Хотя бы в пределах одной СУБД. В каком порядке будет выполняться запрос? Какие индексы будут задействоваться? А будут ли они задействоваться? А как сделать так, чтобы они задействовались? А что произойдёт, если данных будет очень много? А можно ли переписать запрос более эффективно?
Сложно ли это для опытного инженера, съевшего собаку на проектировании баз данных? Вряд ли. Сложно ли это рядовому разработчику, от которого бизнес требует что-то там оптимизировать? Определённо сложно. Настолько сложно, что в некоторых случаях даже и не знаешь, что тебе загуглить чтобы решить вот эту конкретную проблему.
Да, знаю про такой, спасибо за дополнение. Именно реализация аннотаций от EmmyLua была взята за основу в языковом сервере для VSCode. Кстати, вы можете сделать доброе дело и поделиться вашими наработками, опубликовав плагин с типами Тарантула, подробности в этой доке ;)
Второй монитор с документацией на удивление творит чудеса, очень советую : )
Подозреваю, что этот пункт просто ради рофла, иначе мне придётся выяснять, как монитор переносить в рюкзаке :)
Динамические системы автодополнения.
Да, VSCode умеет запоминать введённые слова и в дальнейшем предлагать их для автодополнения. Но всё же это не то же самое, что ввести имя переменной, точку и в выпавшем списке просматривать доступные методы и свойства. А хотелось именно этого.
{fromJust: "WTF? String is not a number!"} расширяет {} - любой объект, поэтому компилятор считает, что это Nothing , а не Just<Number> . По сути, тип Maybe<A> определён как какой угодно объект или {fromJust: A} . Потому эта запись валидна.
Для того чтобы избежать такой ситуации, стоит использовать tyguards. Вот так отработает правильно:
type A = {
x: number;
};
type B = {
x: number;
y: number;
};
function isB(param: object): param is B {
return 'a' in param && param.a instanceof Number && 'y' in param && param.y instanceof Number;
}
const f = (param: A | B): void => {
if (isB(param)) {
// здесь param почему-то B, вместо очевидного A & {y: unknown}
console.log(param.y.toFixed());
}
};
const obj = {
x: 1,
y: null,
};
f(obj);
Опять же, для того чтобы не опростоволоситься - нужно заранее знать, что TS в приведённом тобой примере будет вести себя таким образом.
Либо, как вариант, проверить можно вот так:
if ('y' in param && (param as any).y instanceof Number)
Но я с тобой согласен и в твоём примере такого поведения TS не ожидал.
A & { y: unknown } это тип, который расширяет А. Вполне логично, что я могу передать его в функцию, и до передачи в функцию TS это учитывает. А вот внутри функции уже забывает от этом. Проблема в том, что TS здесь считает что все, что имеет х и у - это B, но это не так, потому что у у B ограничен конкретным типом number.
Да, это я проверил уже не с телефона, действительно поведение не очевидное. То, что функция принимает всё, что расширяет A - это логично, так и должно быть. С толку сбивает другое - проверка на 'y' in param сужает тип с A | B до B, хотя должно бы сужать до A & { y: unknown } .
Да, согласен с тобой. Действительно неожиданное поведение. Для меня странно что in в таком контексте почему-то работает как typeguard, хотя я этого не ожидаю. Как и ты, при написании такого я был бы уверен, что после проверки на наличие ключа TS должен бы вывести A & { y: unknown } .
Предположу, что человек имел ввиду отсутствие номинальной системы типов в TS. Проблема действительно есть, но преимущества типизации она, конечно же, на нет ни в коем разе не сводит. Где-то читал, что номинальную систему в будущем всё же хотят ввести. Сейчас проблема частично решается брендированием.
Garantex - непосредственно биржа с выводом рублей.
До того как Бинанс прищучили, в основном использовал его.
До того как Коммекс слился, также использовал его в основном.
Тема хайповая, для того чтобы найти по ней нужную информацию, достаточно просто перейти на главную страницу поиска Яндекс и задать интересующий вопрос.
Яркий пример - ls в Shell и ls в PowerShell. К первому привык довольно давно, пальцы без команды мозга вводят ls -lah. И вот когда нужно то же самое сделать в винде, пальцы тоже не задумываясь вводят ls -lah. Но только в винде это выбрасывает исключение, потому что там те же самые ключи интерпретируются совершенно иначе. В итоге приходится следить за пальцами и на винде вводить толькоls - результат выполнения по сути тот же самый что и ls -lah на линуксе.
Да, первого апреля.
В случае многих писателей можно смело утверждать, что эти писатели тоже где-то создаются и кем-то ожидаются. Соответственно, этот кто-то ждёт пока отработают все писатели и закрывает канал, в который отправлялись данные.
Не знаю зачем я тут вклиниваюсь, но всё же вклинюсь. Таки согласен. Не понимаю, почему людей так интересуют именно декораторы в питоне, ведь этот паттерн реализуем везде, где можно объявлять функции высшего порядка. Всё то же самое можно делать и в каком-нибудь условном JS, только без синтаксического сахара.
Когда думаешьо декораторе просто как о функции, принимающей в качестве аргумента другую функцию, вся магия куда-то улетучивается.
Очевидно кому?
Использование апелляции к очевидности говорит мне о том, что по существу вам всё же нечего написать.
А я совета не просил) Я попросил объяснить, что не так в коде автора?
Смешно. Нет.
Что не так? Автор этого кода явно прописал, что происходит только обработка значений true и false. Если там, например, null или, не дай бог, пустой массив (мне доводилось видеть всякое), ничего не произойдёт.
Вот эта ремарка вызывает ощущение, будто автор очень мало и очень поверхностно поработал как с ORM, так и с SQL. Хотя сама статья, если честно, вызвала прямо противоположные чувства.
Можно сколько угодно спорить о том, какой подход более "трушный" - замаппить данные самостоятельно или использовать ORM. Но вот сомневаться в сложности как одного, так и второго метода - как минимум подозрительно.
Самое первое, что приходит мне на ум, когда я слышу о том, что писать запросы (на чистом SQL или через ORM - не важно) это просто - это попросить автора этих слов разобрать порядок выполнение какого-нибудь более-менее сложного запроса. Хотя бы в пределах одной СУБД. В каком порядке будет выполняться запрос? Какие индексы будут задействоваться? А будут ли они задействоваться? А как сделать так, чтобы они задействовались? А что произойдёт, если данных будет очень много? А можно ли переписать запрос более эффективно?
Сложно ли это для опытного инженера, съевшего собаку на проектировании баз данных? Вряд ли. Сложно ли это рядовому разработчику, от которого бизнес требует что-то там оптимизировать? Определённо сложно. Настолько сложно, что в некоторых случаях даже и не знаешь, что тебе загуглить чтобы решить вот эту конкретную проблему.
Да, знаю про такой, спасибо за дополнение. Именно реализация аннотаций от EmmyLua была взята за основу в языковом сервере для VSCode. Кстати, вы можете сделать доброе дело и поделиться вашими наработками, опубликовав плагин с типами Тарантула, подробности в этой доке ;)
Подозреваю, что этот пункт просто ради рофла, иначе мне придётся выяснять, как монитор переносить в рюкзаке :)
Да, VSCode умеет запоминать введённые слова и в дальнейшем предлагать их для автодополнения. Но всё же это не то же самое, что ввести имя переменной, точку и в выпавшем списке просматривать доступные методы и свойства. А хотелось именно этого.
{fromJust: "WTF? String is not a number!"}расширяет{}- любой объект, поэтому компилятор считает, что этоNothing, а неJust<Number>. По сути, типMaybe<A>определён как какой угодно объект или{fromJust: A}. Потому эта запись валидна.Для того чтобы избежать такой ситуации, стоит использовать tyguards. Вот так отработает правильно:
Опять же, для того чтобы не опростоволоситься - нужно заранее знать, что TS в приведённом тобой примере будет вести себя таким образом.
Либо, как вариант, проверить можно вот так:
Но я с тобой согласен и в твоём примере такого поведения TS не ожидал.
A & { y: unknown }это тип, который расширяетА. Вполне логично, что я могу передать его в функцию, и до передачи в функцию TS это учитывает. А вот внутри функции уже забывает от этом. Проблема в том, что TS здесь считает что все, что имеет х и у - это B, но это не так, потому что у у B ограничен конкретным типом number.Да, это я проверил уже не с телефона, действительно поведение не очевидное. То, что функция принимает всё, что расширяет
A- это логично, так и должно быть. С толку сбивает другое - проверка на'y' in paramсужает тип сA | BдоB, хотя должно бы сужать доA & { y: unknown }.Да, согласен с тобой. Действительно неожиданное поведение. Для меня странно что
inв таком контексте почему-то работает как typeguard, хотя я этого не ожидаю. Как и ты, при написании такого я был бы уверен, что после проверки на наличие ключа TS должен бы вывестиA & { y: unknown }.Прости, а что странного в приведённом тобой примере?
Предположу, что человек имел ввиду отсутствие номинальной системы типов в TS. Проблема действительно есть, но преимущества типизации она, конечно же, на нет ни в коем разе не сводит. Где-то читал, что номинальную систему в будущем всё же хотят ввести. Сейчас проблема частично решается брендированием.
Exnode - список криптообменников.
Garantex - непосредственно биржа с выводом рублей.
До того как Бинанс прищучили, в основном использовал его.
До того как Коммекс слился, также использовал его в основном.
Тема хайповая, для того чтобы найти по ней нужную информацию, достаточно просто перейти на главную страницу поиска Яндекс и задать интересующий вопрос.
Да и крипту в рубли превратить тащемто далеко не проблема. А это всегда хорошо, когда единственный способ получить оплату из-за рубежа - это крипта.
Яркий пример - ls в Shell и ls в PowerShell. К первому привык довольно давно, пальцы без команды мозга вводят
ls -lah. И вот когда нужно то же самое сделать в винде, пальцы тоже не задумываясь вводятls -lah. Но только в винде это выбрасывает исключение, потому что там те же самые ключи интерпретируются совершенно иначе. В итоге приходится следить за пальцами и на винде вводить толькоls- результат выполнения по сути тот же самый что иls -lahна линуксе.