тупанул просто((

- у вас есть такой же, но без re? - нет! - будем искать...

Всем привет, нужен совет. Есть две функции, которые отличаются совсем немногим - во второй на 3-4 строчки больше и вместо одного элемента она возвращает кортеж из двух элементов. Как их можно изящнее реализовать? Пути решения: 1. Передавать в общую функцию аргумент, от которого зависит, что мы будем делать. В тело функции добавить условия. - Но эта функция будет выполняться много раз и проверять if при каждом вызове не хотелось бы. 2. Просто скопировать первую функцию и дописать то, что нужно. - Слишком много повторяющегося кода. Но если промежуточные действия тоже обернуть в функции, то эту ситуацию можно немного улучшить. 3. Как-то хитро использовать декораторы. - Пока не могу придумать, как.

а нельзя это в одну функцию запихнуть?

раз 3-4 строчками отличаются, можно добавить условие какое-нибудь

Если нужно изменить работу функция не изменяя самой функции - используй декоратор

раз 3-4 строчками отличаются, можно добавить условие какое-нибудь

Можно, но если она будет запускаться миллион раз, не сильно ли это скажется на быстродействии?

Если нужно изменить работу функция не изменяя самой функции - используй декоратор

Я тоже думал в сторону декораторов, но пока не знаю, как их приспособить.

timeit в руки и вперед мерять

как раз по умолчанию 10000-100000000 раз гоняет

оборачивание в декоратор еще дороже обойдется

timeit в руки и вперед мерять

Тоже верно, померяю, спасибо.

В некоторых ситуациях простой копипастинг не такой уж и ужасный. Если метод практически гарантировано устоялся, переписывать его не планируется, размер кода не критичен, а к производительности большое требование - велком. Но как правило такие штуки возникают из-за неоптимизированной архитектуры.

копипастинг это зло когда "а, я не знаю, что тут такое, но вроде работает"

В некоторых ситуациях простой копипастинг не такой уж и ужасный. Если метод практически гарантировано устоялся, переписывать его не планируется, размер кода не критичен, а к производительности большое требование - велком. Но как правило такие штуки возникают из-за неоптимизированной архитектуры.

Пока что это исключительно для личного пользования в тетрадке, но всё равно хочется сделать хорошо. :)

Через полгода в любом проекте начинается "а я не помню как это работает" :))

Если в тетрадке и для личного, и для обучения - тогда а) я бы посмотрел "сверху" на архитектуру, с целью вообще посмотреть почему так получилось и как может взглянуть на предмет с другой стороны, составить по другому классы (если это ООП). Если речь про обучение, до декораторы я бы не использовал со смыслом "расширение функционала метода", декораторы всё-таки про смысл "изменение свойств метода". Тут скорее разбитие кода на части и последовательное выполнение методов.

макос это отлично для разработчика, brew лучше линуксовых пакетных менеджеров, iterm2 лучше любого линуксового терминала, система не обделена софтом, интрефейс макос очень удобный, железо опять же очень приятное

и все это неправда

макос это отлично для разработчика, brew лучше линуксовых пакетных менеджеров, iterm2 лучше любого линуксового терминала, система не обделена софтом, интрефейс макос очень удобный, железо опять же очень приятное

на том, что брю лучше, я подавился

и все это неправда

понеслась пизда по кочкам

на том, что брю лучше, я подавился

вот-вот :)

не все неправда

Сложно поспорить с тем, что "железо опять же очень приятное"

на том, что брю лучше, я подавился

я тоже сначала подавился, а потом подумал, чем он хуже хочешь - компиль из исходников, хочешь - забирай бинарники. по умолчанию - бинарники. куча дружелюбных опций в пределах пакетов, не надо никакого ./configure --with.

репа на гитхабе -> софт доезжает быстро, бинарники собираются автоматически ботами

гитхаб? хипстерство ебаное, да. но актуальность репозитория вполне себе неплохо поддерживается.

он хуже тем, что это сраный костыль на руби, который официальные релизы обмазывает кучей патчей и пытается кое-как не вступить в конфликт с системными либами и XCode

хочешь - храни несколько версий пакета и переключайся между ними как тебе угодно

расскажите как обновить питончик через брю в маках нормально?

> кучей патчей пиздёж > кое-как не вступить в конфликт с системными либами и XCode такое редко бывает

по сравнению с нормальной пакетной системой это - феерическое говно, но без него было бы еще хуже, я согласен

расскажите как обновить питончик через брю в маках нормально?

brew upgrade python3?

> пиздёж факт

> пиздёж факт

пруф

brew upgrade python3?

второй, который уже есть в системе

открой практически любой рецепт

открой практически любой рецепт

ты гонишь - ты и открывай :)

второй, который уже есть в системе

тогда brew install python

и это не "обнбовить питончик"

это "поставить еще один питончик"

ты гонишь - ты и открывай :)

так это ты сказал, что пиздеж - ты и подтверждай

это "поставить еще один питончик"

вот этим брю и хуже

нахрена мне две копии одного софта?

вот этим брю и хуже

чем?? Да, это нестандартный менеджер пакетов

Ты ебанулся? Нахрена брю трогать системный питон?

Поговори вон с энчантером, че будет, если ставить че-нибудь в системный питон без венвов

а нахрена мне ставить из брю второй раз то, что итак уже есть

а нахрена мне ставить из брю второй раз то, что итак уже есть

ты сказал что хочешь поставить, я тебе сказал как, ты доебался до такой хуйни, серьезно щас?

так это ты сказал, что пиздеж - ты и подтверждай

Ок, погнали. https://github.com/Homebrew/homebrew-core/tree/master/Formula/zsh.rb - 0 патчей

а нахрена мне ставить из брю второй раз то, что итак уже есть

системный питон тебе не нужен от слова вообще

ты сказал что хочешь поставить, я тебе сказал как, ты доебался до такой хуйни, серьезно щас?

да, вполне серьезно, сделано через жопу? сделано через жопу

https://github.com/Homebrew/homebrew-core/blob/master/Formula/nano.rb - 0 патчей

да, вполне серьезно, сделано через жопу? сделано через жопу

что именно сделано через жопу-то?

Если в тетрадке и для личного, и для обучения - тогда а) я бы посмотрел "сверху" на архитектуру, с целью вообще посмотреть почему так получилось и как может взглянуть на предмет с другой стороны, составить по другому классы (если это ООП). Если речь про обучение, до декораторы я бы не использовал со смыслом "расширение функционала метода", декораторы всё-таки про смысл "изменение свойств метода". Тут скорее разбитие кода на части и последовательное выполнение методов.

Спасибо, натолкнуло на полезную мысль. :)

это сделано максимально пиздато, как могли сделать левые люди, не связанные с эпплом

https://github.com/Homebrew/homebrew-core/blob/master/Formula/gcc.rb - опа, один патч! целый один! для такого проекта, как гцц!

по сравнению с нормальной пакетной системой это - феерическое говно, но без него было бы еще хуже, я согласен

А вот и наш старый друг

В общем, Николай, пока ты проигрываешь

Ок, погнали. https://github.com/Homebrew/homebrew-core/tree/master/Formula/zsh.rb - 0 патчей

https://github.com/Homebrew/homebrew-core/blob/master/Formula/coreutils.rb "качаем в процессе какую-то херню из macports, размазываем ровным слоем по системе"

Для yosemite. Это старая версия. Этот патч сейчас никому накатываться не будет.

это сделано максимально пиздато, как могли сделать левые люди, не связанные с эпплом

про "пиздато" не соглашусь, но это на безрыбье работает

https://github.com/Homebrew/homebrew-core/search?utf8=%E2%9C%93&q=+patch+do&type=

брю решает задачу установки пакетов на макос, криво, через жопу, но решает

ERROR: S client not available

но сравнивать его с нормальными пакетными менеджерами - это смешно

это сделано максимально пиздато, как могли сделать левые люди, не связанные с эпплом

никто не спорит с этим тезисом. сделано неплохо, но это в любом случае хуже, чем нормальный пакетный менеджер

ОК, какие плюсы "нормального пакетного менеджера"?

и кстати

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=coreutils-progress-git

лол

ОК, какие плюсы "нормального пакетного менеджера"?

не патчит исходники на лету?

source=("git+git://git.sv.gnu.org/coreutils.git" '0001-copy-Add-a-progress-option.patch' '0002-copy-fix-missing-progress-check.patch' '0003-copy-fix-two-potential-divs-by-zero.patch')

не патчит исходники на лету?

че, арчлинукс теперь тоже не нужен?

че, арчлинукс теперь тоже не нужен?

а в арчлинуксе появилось то, что можно назвать "пакетным менеджером"?

сейчас мы дойдем до того, что emerge начнем так называть

это ты серьезно щас?

а в арчлинуксе появилось то, что можно назвать "пакетным менеджером"?

нркмн?

не патчит исходники на лету?

алоэ, блядь. открывай еще раз и посмотри на замечательные строчки

https://github.com/Homebrew/homebrew-core/blob/master/Formula/coreutils.rb#L42-L44

знаешь, что это значит?

это значит, что он скачает бинарники и не будет ничего патчить сам

нет, просто в современном мире основных форматов пакетов два - rpm и deb. Остальное чаще всего попытка совместить бинарно совместимые elfы и патчинг исходников.

это значит, что он скачает бинарники и не будет ничего патчить сам

ага, то есть выше ты слово patch глазами не видишь

чувак. давай еще раз

я лучше знаю, как homebrew работает ;)

чувак. давай еще раз

https://github.com/Homebrew/homebrew-core/blob/master/Formula/coreutils.rb#L34-L37

патчи не будут накатываться, если 1) ты не собираешь из исходников (а ты не собираешь по умолчанию, т.к. ниже указаны бутылки)

2) (в данном случае) если у тебя >= yosemite

Ох, прям как в старые добрые

т.е. три последние версии ОС

2) (в данном случае) если у тебя >= yosemite

и как это меняет тот факт, что это набор сраных костылей?

по твоей логике, можно и Ansible использовать, как пакетный менеджер

и как это меняет тот факт, что это набор сраных костылей?

так ты мне сам говоришь что dpkg/yum или че там ничего не патчат, а homebrew - кококо - патчит

а на деле такой вот логики в пакетном менеджере в принципе быть не должно

патчи не будут накатываться, если 1) ты не собираешь из исходников (а ты не собираешь по умолчанию, т.к. ниже указаны бутылки)

я правильно понимаю, что бинарники для йосемите уже с этими патчами собраны?