RH
Это немного другое, ASIO и т.п. - чтобы уменьшить задержку с входа микрофона/линии до выхода. В основном для подключения музыкальных инструментов нужно
Size: a a a
2020 January 09
AS
да, про него
SZ
SB
А нет ни у кого на примете бота который бы автодетектировал язык, и если это не заданный, например английский и русский, то переводил бы на английский/ русский через гугул, например?
SB
Именно
БС
рекомендую, хорошо рассказывает.
у меня нету линтера и я не хочу ревьювить :(
у меня нету линтера и я не хочу ревьювить :(
можешь в кратце рассказать о чем доклад?
SZ
можешь в кратце рассказать о чем доклад?
Линтер - это хорошо, линтер, заставляющий тебя страдать - замечательно, Линтер, который заставит тебя всё переписать - твой лучший друг
БС
а он что нибудь сложнее хелоуворлд писал? Но с таким описанием, можно будет и посмотреть
SZ
а он что нибудь сложнее хелоуворлд писал? Но с таким описанием, можно будет и посмотреть
Видимо писал
KK
Он(и) написали линтер с 4к тестами 😊
RB
а он что нибудь сложнее хелоуворлд писал? Но с таким описанием, можно будет и посмотреть
Он dry-python с Артемом пишет. Но доклады мне не нравятся, хотя линтеры люблю.
KK
В их линтере мне не нравится только то, что он "банит" f-строки, потому что они не "добавляют ни чего нового", но при этом вносят дополнительный, отличающийся синтаксис. Т.е. снижается "консистентность" - в одном месте у тебя f-строки, в другом проценты или .format(). Поэтому они разрешают только .format(), а всё остальное запрещают.
И никто не указал на то, что f-строки банально работают быстрее, а .format() вообще самый медленный из возможных вариантов. И я ради этой скорости готов мирится с тем что внутрь них можно запихать логику (лечится тем же линтером), и их несколько сложнее перемещать по коду, т.к. их работа зависит от локального контекста.
И никто не указал на то, что f-строки банально работают быстрее, а .format() вообще самый медленный из возможных вариантов. И я ради этой скорости готов мирится с тем что внутрь них можно запихать логику (лечится тем же линтером), и их несколько сложнее перемещать по коду, т.к. их работа зависит от локального контекста.
RB
А в каких единицах измеряется этот выигрыш в скорости?
KK
В разах
KK
А в каких единицах измеряется этот выигрыш в скорости?
In [1]: name = 'User'
In [2]: timeit f'Hello {name}'
49.1 ns ± 0.319 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)
In [5]: tpl = 'Hello {name}'
In [6]: timeit tpl.format(name=name)
238 ns ± 1.51 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)
БС
Он dry-python с Артемом пишет. Но доклады мне не нравятся, хотя линтеры люблю.
А что я должен понять из того что он пишет dry-python? Что он чертов гений? Или его мнение единственное верное?
Линтеры я тоже люблю, предпочитаю пичармовский. И я очень стараюсь чтобы не было желтеньких подчеркиваний. Но иногда сделать довольным линтер стоит слишком дорого. Можно задисэблить какую то либо проверку на весь файл/функцию, либо игнорировать подчеркивание.
Жалко что пичармовский линтер без дополнительных приседаний нельзя запустить в CI.
Линтеры я тоже люблю, предпочитаю пичармовский. И я очень стараюсь чтобы не было желтеньких подчеркиваний. Но иногда сделать довольным линтер стоит слишком дорого. Можно задисэблить какую то либо проверку на весь файл/функцию, либо игнорировать подчеркивание.
Жалко что пичармовский линтер без дополнительных приседаний нельзя запустить в CI.
KK
А что я должен понять из того что он пишет dry-python? Что он чертов гений? Или его мнение единственное верное?
Линтеры я тоже люблю, предпочитаю пичармовский. И я очень стараюсь чтобы не было желтеньких подчеркиваний. Но иногда сделать довольным линтер стоит слишком дорого. Можно задисэблить какую то либо проверку на весь файл/функцию, либо игнорировать подчеркивание.
Жалко что пичармовский линтер без дополнительных приседаний нельзя запустить в CI.
Линтеры я тоже люблю, предпочитаю пичармовский. И я очень стараюсь чтобы не было желтеньких подчеркиваний. Но иногда сделать довольным линтер стоит слишком дорого. Можно задисэблить какую то либо проверку на весь файл/функцию, либо игнорировать подчеркивание.
Жалко что пичармовский линтер без дополнительных приседаний нельзя запустить в CI.
Название доклада как бы намекает, что тема и мнение докладчика очень холиварные.
БС
В их линтере мне не нравится только то, что он "банит" f-строки, потому что они не "добавляют ни чего нового", но при этом вносят дополнительный, отличающийся синтаксис. Т.е. снижается "консистентность" - в одном месте у тебя f-строки, в другом проценты или .format(). Поэтому они разрешают только .format(), а всё остальное запрещают.
И никто не указал на то, что f-строки банально работают быстрее, а .format() вообще самый медленный из возможных вариантов. И я ради этой скорости готов мирится с тем что внутрь них можно запихать логику (лечится тем же линтером), и их несколько сложнее перемещать по коду, т.к. их работа зависит от локального контекста.
И никто не указал на то, что f-строки банально работают быстрее, а .format() вообще самый медленный из возможных вариантов. И я ради этой скорости готов мирится с тем что внутрь них можно запихать логику (лечится тем же линтером), и их несколько сложнее перемещать по коду, т.к. их работа зависит от локального контекста.
имхо
f string и % это прям python way. А format это прям жава и прочие языки с жесткой типизацией
"".format() это прям было супер не удачное решение. Столько лишних буковок и скобочек.f string и % это прям python way. А format это прям жава и прочие языки с жесткой типизацией