Я делал ласик лет 15 назад, тогда скосили часть «минуса»: до 3,75 для левого и 5,75 для правого (изначальные показатели я уже не помню и не помню, почему не докорректировали). Пару лет назад мне отказались проводить повторную коррекцию в Минске поскольку роговица этого не позволяет. Где-то недавно читал, что факичные линзы после ласика не устанавливают. Страшно спрашивать, если честно, но узнать надо: проводится ли имплантация факичных линз после перенесенной операции ласик?
Я сказал ровно то, что сказал: автор комментария захотел фильтр + предикат. Я предложил ему генератор, который лучше писать развернуто. Так-то compose(distinct, partial(filter, pred), validator).
Отвечу сразу на два ваших комментария: во-первых, спасибо за лестный отзыв выше, очень непросто написать статью и учесть знания/опыт всей аудитории, и уместить это в размере поста; во-вторых, реальный пример:
@post_mapping(foo)
def bar(self, data):
yield from cat(keep('key', data.values()))
yield self.baz
Тут, конечно, потребуется знания этих странных функций. Но в любой команде рано или поздно появляется свой набор утилит, которыми пользуются все. В нашем случае это набор функциональных тулов аналогичных funcy. Аналогичных, потому что у нас они работают чуточку иначе.
И так:
post_mapping вызовет foo на каждый элемент отданным генератором, аналог map(foo, bar()). Только не придется писать это всякий раз
cat — это шорткат к itertools.chain.from_iterable — склеивает массивы вместе в один
keep — это комбинация "достань по ключу key и дропни фолс-значения"
По порядку:
из значений словаря по ключу key достаются значения (в данном случае это массивы), затем удаляются пустые, затем объединяются в один и отдаются
в хвост генератора добавляется self.baz
все элементы обрабатываются функцией foo
Императивно это выглядит раза в 4 больше. И дело тут не в размере, а в том, что используя одни и те же инструменты (и понимая как они работают), вам не нужно читать и писать код, который делает то же самое, но конкретно тут и конкретно так каждый раз.
Ура, вы написали функцию. Да, предикат повторно использовать не сможете, но сделали же по моему! :) И вот так (seq + seq2) не стоит делать. Во-первых, не работает с ленивыми, во-вторых, вы получите третий список/тапл.
Где ж оно короче? ) Давайте считать, берем два массива:
filtered = filter_none(seq)
filtered2 = filter_none(seq2)
all_filtered = filter_none(chain(seq, seq2))
# versus
filtered = (x for x in seq if x is not None)
filtered2 = (x for x in seq2 if x is not None)
all_filtered = (y for x in (seq, seq2) for y in x if y is not None)
Правда круто бойлерплейта налетает, если сделать хотя бы два раза то же самое?
Да боже мой ) Это пример. Самый простой. Для простого понимания. Вот вам, положите на фильтр:
def foo(seq):
if not isinstance(seq, bar) or baz(seq):
raise Exception('Bad seq')
seen = set()
for x in seq:
if egg(x) and x not in seen:
seen.add(x)
yield x
В таком примере слишком много лишнего, чего я не собирался говорить.
Это просто пример, для легкого понимания. И коли это уже второй (третий?) подобный коммент: лично я не фанат использовать None в качестве предиката. Потому что он фильтрует не только наны.
Если написать функцию для удаления нанов и затем ее протестировать, не придется тестировать ее поведение в каждом частном куске кода. Код будет меньше, код будет проще, код будет стабильнее. Функции в отдельности, композированные тоже, конечно нужно тестировать.
Про "далеки от народа" не понял. Хотя могу предположить, что я предлагаю несколько непривычный для python подход — все в порядке, я уже делаю это не в первый раз. Сначала никому не нравится, потом за уши не оторвать. Уж очень красочно выглядит экран функций из одних compose.
Кстати, это не синтетика, я этим реально пользуюсь в работе. На том же pluck (более сложном, конечно же) у меня построен мини DSL для работы со списками и словарями — выкинули кучу кода.
Если вы о февральской прошивке, то там прилично багов. Самые запоминающиеся: при звонке у меня не включился экран и хоть тресни, нельзя было ответить на звонок. Второе: сканер пальцев определялся не во всех приложениях. Да и не весь софт работал.
Если он что-то новее релизил, поделитесь, пожалуйста, ссылкой (можно в личку).
Кстати, «васяня», вероятно, работает в сяоми и сливает инсайд рискуя своим местом, поэтому он просит не размещать посты о прошивке на китайских форумах.
Т.е. вы сравниваете синхронную джангу с го. Ооокей.
Я сказал ровно то, что сказал: автор комментария захотел фильтр + предикат. Я предложил ему генератор, который лучше писать развернуто. Так-то
compose(distinct, partial(filter, pred), validator)
.У фильтра нет метода
dedup()
и вы вынесли проверку уровнем выше. Т.е. вам придется ее писать всякий раз.Потому что вы это сделали в том же скопе (консоль, модуль). Ваш пример нежизнеспособен:
Вы можете написать свой компоуз, который склеивает хелпы и собирает красивую доку, я не прошу пользоваться своей реализацией, она "примерная".
И при всем уважении, я не стал бы работать в команде, где кто-то лезет в чужой модуль, патчит очевидные вещи и потом жалуется на нерабочий код.
Отвечу сразу на два ваших комментария: во-первых, спасибо за лестный отзыв выше, очень непросто написать статью и учесть знания/опыт всей аудитории, и уместить это в размере поста; во-вторых, реальный пример:
Тут, конечно, потребуется знания этих странных функций. Но в любой команде рано или поздно появляется свой набор утилит, которыми пользуются все. В нашем случае это набор функциональных тулов аналогичных
funcy
. Аналогичных, потому что у нас они работают чуточку иначе.И так:
post_mapping
вызоветfoo
на каждый элемент отданным генератором, аналогmap(foo, bar())
. Только не придется писать это всякий разcat
— это шорткат кitertools.chain.from_iterable
— склеивает массивы вместе в одинkeep
— это комбинация "достань по ключуkey
и дропни фолс-значения"По порядку:
key
достаются значения (в данном случае это массивы), затем удаляются пустые, затем объединяются в один и отдаютсяself.baz
foo
Императивно это выглядит раза в 4 больше. И дело тут не в размере, а в том, что используя одни и те же инструменты (и понимая как они работают), вам не нужно читать и писать код, который делает то же самое, но конкретно тут и конкретно так каждый раз.
И оно ленивое!
Ура, вы написали функцию. Да, предикат повторно использовать не сможете, но сделали же по моему! :) И вот так
(seq + seq2)
не стоит делать. Во-первых, не работает с ленивыми, во-вторых, вы получите третий список/тапл.Где ж оно короче? ) Давайте считать, берем два массива:
Правда круто бойлерплейта налетает, если сделать хотя бы два раза то же самое?
Да боже мой ) Это пример. Самый простой. Для простого понимания. Вот вам, положите на фильтр:
В таком примере слишком много лишнего, чего я не собирался говорить.
Это просто пример, для легкого понимания. И коли это уже второй (третий?) подобный коммент: лично я не фанат использовать
None
в качестве предиката. Потому что он фильтрует не только наны.Делайте проще:
Импорт-то прочитать не сложно. Ну и по опыту: в большом проекте это "2-5" строк кода множатся как грибы после дождя, причем бессмысленно.
Все проще: map, filter и reduce питонисты не используют. Я серьезно.
Держите:
Я немного слукавил, вы правы, надо было как-то подвести к функциям высшего порядка. Надеюсь, вы не подменяете функции в рантайме?
Дело привычки, поверьте.
Если написать функцию для удаления нанов и затем ее протестировать, не придется тестировать ее поведение в каждом частном куске кода. Код будет меньше, код будет проще, код будет стабильнее. Функции в отдельности, композированные тоже, конечно нужно тестировать.
Про "далеки от народа" не понял. Хотя могу предположить, что я предлагаю несколько непривычный для python подход — все в порядке, я уже делаю это не в первый раз. Сначала никому не нравится, потом за уши не оторвать. Уж очень красочно выглядит экран функций из одних
compose
.Кстати, это не синтетика, я этим реально пользуюсь в работе. На том же
pluck
(более сложном, конечно же) у меня построен мини DSL для работы со списками и словарями — выкинули кучу кода.Если он что-то новее релизил, поделитесь, пожалуйста, ссылкой (можно в личку).
Кстати, «васяня», вероятно, работает в сяоми и сливает инсайд рискуя своим местом, поэтому он просит не размещать посты о прошивке на китайских форумах.