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

Здесь вопрос именно в том, что это только подтверждает наличие проблемы и стыдливо её прячет, ничего не решая при этом.

Здесь вопрос именно в том, что это только подтверждает наличие проблемы и стыдливо её прячет, ничего не решая при этом.

Это всё моё личное мнение, а ими мы тут и обмениваемся

Это всё моё личное мнение, а ими мы тут и обмениваемся

Хорошо, вот вам мое мнение: Мне кажется, мы просто не можем понять носителей оригинального языка, например Если бы у нас стояла так остро проблема исторического неравенства и этих самых "терминов", возможно мы бы не считали это чьей-то шуткой и тп А так для неносителей языка вроде нас с вами это и правда просто "термины" без абсолютного контекста (я впервые это встретил еще в начальной школе, кажется, исключительно в техническом контексте даже не понимая что слово оригинальное означает - разумеется я не вижу в них ничего крамольного) Будь в каком-нибудь нашем 1С термины "раб" и "хозяин" - мне бы это тоже странным показалось. А если бы еще надо мной люди другой расовой принадлежности издевались (как все ща пишут про негров, что наконец будут писать на питоне и прочие непотребства), я бы это еще и полным оскорблением посчитал бы

Хорошо, вот вам мое мнение: Мне кажется, мы просто не можем понять носителей оригинального языка, например Если бы у нас стояла так остро проблема исторического неравенства и этих самых "терминов", возможно мы бы не считали это чьей-то шуткой и тп А так для неносителей языка вроде нас с вами это и правда просто "термины" без абсолютного контекста (я впервые это встретил еще в начальной школе, кажется, исключительно в техническом контексте даже не понимая что слово оригинальное означает - разумеется я не вижу в них ничего крамольного) Будь в каком-нибудь нашем 1С термины "раб" и "хозяин" - мне бы это тоже странным показалось. А если бы еще надо мной люди другой расовой принадлежности издевались (как все ща пишут про негров, что наконец будут писать на питоне и прочие непотребства), я бы это еще и полным оскорблением посчитал бы

Это тоже правильно. Соглашусь, нам понять сложно

Хорошо такое предлагать, когда свалил;)

Он же не свалил, а снял с себя полномочия единовластного правителя)

Хорошо, вот вам мое мнение: Мне кажется, мы просто не можем понять носителей оригинального языка, например Если бы у нас стояла так остро проблема исторического неравенства и этих самых "терминов", возможно мы бы не считали это чьей-то шуткой и тп А так для неносителей языка вроде нас с вами это и правда просто "термины" без абсолютного контекста (я впервые это встретил еще в начальной школе, кажется, исключительно в техническом контексте даже не понимая что слово оригинальное означает - разумеется я не вижу в них ничего крамольного) Будь в каком-нибудь нашем 1С термины "раб" и "хозяин" - мне бы это тоже странным показалось. А если бы еще надо мной люди другой расовой принадлежности издевались (как все ща пишут про негров, что наконец будут писать на питоне и прочие непотребства), я бы это еще и полным оскорблением посчитал бы

Я бы очень веселилась если бы в 1С были термины Боярин и Крепостной

Давайте уж полностью зеркалить, со всеми историческими контекстами)

Давайте уж полностью зеркалить, со всеми историческими контекстами)

И не worker, а батрак!

Да, можно и так Но опять же, у нас эти исторические болячки так остро не стоят как в США с ущемлением прав меньшинств или как в Германии с нацизмом - для них это по сей день больная в целом тема

В то время как у нас вовсю в чатиках стикеры с гитлерами и прочая ерунда

Ну да, когда в Америке ущемляли одну расу, у нас ущемляли практически 80% населения поэтому не остро. Че обижаться когда в жопе почти все))

Но мне кажется это уже оффтоп от канала

Я бы очень веселилась если бы в 1С были термины Боярин и Крепостной

А там можно;) А ещё "Счетик" и "Проводочка"

Мне кажется, что та-же алхимия не сильно подходит по паттерн IoC

IoC -- не паттерн!

А там можно;) А ещё "Счетик" и "Проводочка"

))

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

У языка программирования нет логики. Логика есть в программе, которая на нём написана.

У языка программирования нет логики. Логика есть в программе, которая на нём написана.

Ну это придирка же. «Логика работы» == «как работает» или «принципы устройства»

IoC -- не паттерн!

Лаааааадно

IoC -- не паттерн!

Do you state that there's no pattens except Patterns and GoF is a messenger of Pattens?

О, споры о терминах

Do you state that there's no pattens except Patterns and GoF is a messenger of Pattens?

I do believe

Ну, гоф устарела всё-таки.

Ну, гоф устарела всё-таки.

Устарела в каком смысле?

"Гоф умер"

Устарела в каком смысле?

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

Тот же ИоЦ/Ди сейчас стал паттерном который считается что знают все, а его там и рядом нет.

на динамические языки необязательно натягивать паттерны из GOF в чистом виде со всеми интерфейсами и т. п. Их можно адаптировать. Вот, например, коллекция паттернов на Python https://github.com/faif/python-patterns

на динамические языки необязательно натягивать паттерны из GOF в чистом виде со всеми интерфейсами и т. п. Их можно адаптировать. Вот, например, коллекция паттернов на Python https://github.com/faif/python-patterns

я в курсе, да.

Так всё-таки gof как бы не совсем умер, пока мы о нём помним ?

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

А раньше работала?

Вот так было во вторник в Фениксе https://spbpython.guru/news/photo-20180911 #meetup #photo

Вот так было во вторник в Фениксе https://spbpython.guru/news/photo-20180911 #meetup #photo

Если вы были в Фениксе, стоит ли там еще делать наши митапы? public poll Нет. Туда я больше не хочу – 4 ??????? 50% @lig11, @delimitry, @nonamenix, Andrey Очень круто! Давайте снова там почаще – 3 ????? 38% Mikhail, @dazomai, Aleks Не был, но выглядит неплохо – 1 ?? 13% @sm2te ? 8 people voted so far.

А есть кто в сообществе из EPAM? Если есть, расскажите как там питонистам живётся, много ли проектов или нет и если есть, то что за проекты как правило (имеется в виду направленность)

А есть кто в сообществе из EPAM? Если есть, расскажите как там питонистам живётся, много ли проектов или нет и если есть, то что за проекты как правило (имеется в виду направленность)

@smirnoffmg есть в https://t.me/joinchat/BA9zxD_Df8rTlNpiXhDSig

Спасибо

Привет, мы решили написать на Хабре про ваш подкаст в надежде, что он возродится (ходят слухи, что это возможно): https://habr.com/post/423103/ p.s. Если кто-то хочет удаленно присоединиться к подкастам московского сообщества (это которые с Гришей Петровым), напишите в личку, плз.

Привет, мы решили написать на Хабре про ваш подкаст в надежде, что он возродится (ходят слухи, что это возможно): https://habr.com/post/423103/ p.s. Если кто-то хочет удаленно присоединиться к подкастам московского сообщества (это которые с Гришей Петровым), напишите в личку, плз.

Кто таки подкасты? Это секта ?

Мне кажется, что секта -- это всегда плохо...

Кто таки подкасты? Это секта ?

учитывая, что термин изобрели для эппловского iPod, нельзя ничего исключать)

import this

import this

видимо бот не работает)

import this

The Zen of SPb Python Chat (Inspired by "The Zen of Python, by Tim Peters") - Short introduction of yourself is better than "hello". - Link to gist is better than source paste. - One long message is better than many short. - Editing the message is better than correcting via another one. - Staying on topic is better than offtopic. - Good topic is worth discussing though. - Unless it is started by a link to Habrahabr. - Politeness counts. - Bad mood is not a good reason to break the rules. - Don't ask to ask just ask. - Text message is better than voice message. - Unless it is voice conference. - Git repos are one honking great idea — let's do more of those!

видимо бот не работает)

Да не, у него обед был.

@dataclass (либо namedtuple) и набор функций (процедур) для работы с ними -- это антипаттерн (как здесь пишут: https://en.m.wikipedia.org/wiki/Anemic_domain_model) или норм? Больше контекста: есть пользователи (users), которые подписываются (subscription) на каналы (channels). Их нужно хранить в эластиксерче и отдавать/принимать данные в json (типа пользователи в канале, каналы пользователя, подписывать пользователя на канал и т.п.). Лучше сделать тупые датаклассы user, channel, subscription с отдельными процедурами по их обработке или делать классы с поведением (типа user_foo.subscribe(channel_bar) и т.п.)

@dataclass (либо namedtuple) и набор функций (процедур) для работы с ними -- это антипаттерн (как здесь пишут: https://en.m.wikipedia.org/wiki/Anemic_domain_model) или норм? Больше контекста: есть пользователи (users), которые подписываются (subscription) на каналы (channels). Их нужно хранить в эластиксерче и отдавать/принимать данные в json (типа пользователи в канале, каналы пользователя, подписывать пользователя на канал и т.п.). Лучше сделать тупые датаклассы user, channel, subscription с отдельными процедурами по их обработке или делать классы с поведением (типа user_foo.subscribe(channel_bar) и т.п.)

чорт, еще один Чистяков

@dataclass (либо namedtuple) и набор функций (процедур) для работы с ними -- это антипаттерн (как здесь пишут: https://en.m.wikipedia.org/wiki/Anemic_domain_model) или норм? Больше контекста: есть пользователи (users), которые подписываются (subscription) на каналы (channels). Их нужно хранить в эластиксерче и отдавать/принимать данные в json (типа пользователи в канале, каналы пользователя, подписывать пользователя на канал и т.п.). Лучше сделать тупые датаклассы user, channel, subscription с отдельными процедурами по их обработке или делать классы с поведением (типа user_foo.subscribe(channel_bar) и т.п.)

а чего больше: пользователей или каналов?

@dataclass (либо namedtuple) и набор функций (процедур) для работы с ними -- это антипаттерн (как здесь пишут: https://en.m.wikipedia.org/wiki/Anemic_domain_model) или норм? Больше контекста: есть пользователи (users), которые подписываются (subscription) на каналы (channels). Их нужно хранить в эластиксерче и отдавать/принимать данные в json (типа пользователи в канале, каналы пользователя, подписывать пользователя на канал и т.п.). Лучше сделать тупые датаклассы user, channel, subscription с отдельными процедурами по их обработке или делать классы с поведением (типа user_foo.subscribe(channel_bar) и т.п.)

норм

@dataclass (либо namedtuple) и набор функций (процедур) для работы с ними -- это антипаттерн (как здесь пишут: https://en.m.wikipedia.org/wiki/Anemic_domain_model) или норм? Больше контекста: есть пользователи (users), которые подписываются (subscription) на каналы (channels). Их нужно хранить в эластиксерче и отдавать/принимать данные в json (типа пользователи в канале, каналы пользователя, подписывать пользователя на канал и т.п.). Лучше сделать тупые датаклассы user, channel, subscription с отдельными процедурами по их обработке или делать классы с поведением (типа user_foo.subscribe(channel_bar) и т.п.)

А что мешает добавить к датаклассам и именованным кортежам бизнес логику? Они же, по сути, просто дают "бесплатный" конструктор.

Ну, кортежи ещё, вроде, по памяти выгоднее.

Ну если дело в памяти, можно засунуть _ _ slots _ _ (p.s. парсер лох)

Ну если дело в памяти, можно засунуть _ _ slots _ _ (p.s. парсер лох)

А они разве есть в третьем питоне?

А они разве есть в третьем питоне?

Да вроде есть https://docs.python.org/3/reference/datamodel.html#slots

@dataclass (либо namedtuple) и набор функций (процедур) для работы с ними -- это антипаттерн (как здесь пишут: https://en.m.wikipedia.org/wiki/Anemic_domain_model) или норм? Больше контекста: есть пользователи (users), которые подписываются (subscription) на каналы (channels). Их нужно хранить в эластиксерче и отдавать/принимать данные в json (типа пользователи в канале, каналы пользователя, подписывать пользователя на канал и т.п.). Лучше сделать тупые датаклассы user, channel, subscription с отдельными процедурами по их обработке или делать классы с поведением (типа user_foo.subscribe(channel_bar) и т.п.)

Лучше attrs для данных и классы для логики, которые принимают в конструктор данные инстансом attrs

Лучше attrs для данных и классы для логики, которые принимают в конструктор данные инстансом attrs

Можно и dataclasses вместо attrs. Основная идея - сделать логику независящей от способа получения данных, т.е. сотворить dependency injection и иметь возможность тестировать логику любыми тестовыми данными без эластика или чего бы там ни было

Лучше attrs для данных и классы для логики, которые принимают в конструктор данные инстансом attrs

При этом, это уже будут классы типа какой-нибудь Executor или Chewer, а не User и Subscription. Ну и эти классы могут быть и просто функциями. Это уже как спроектировать

Спасибо за ответы!

Можно и dataclasses вместо attrs. Основная идея - сделать логику независящей от способа получения данных, т.е. сотворить dependency injection и иметь возможность тестировать логику любыми тестовыми данными без эластика или чего бы там ни было

Вот. Вопрос хорошо ли это. Фаулер пишет, что это возвращение от ООП к процедурам

А что мешает добавить к датаклассам и именованным кортежам бизнес логику? Они же, по сути, просто дают "бесплатный" конструктор.

Конкретно с namedtuple неудобно логику добавлять. Если логику добавить прямо в датакласс, то при использовании объекта непонятно когда он ходит в базу, а когда нет. Например, если user_foo.subscribe(channel_bar) ходит в эластиксерч, то почему user_foo.name не ходит? Или я что-то делаю не так?

Конкретно с namedtuple неудобно логику добавлять. Если логику добавить прямо в датакласс, то при использовании объекта непонятно когда он ходит в базу, а когда нет. Например, если user_foo.subscribe(channel_bar) ходит в эластиксерч, то почему user_foo.name не ходит? Или я что-то делаю не так?

class MyBrandNewNamedTuple(namedtuple('MyBrandNewNamedTuple', ('brand', 'weight', 'color')): pass Такую конструкцию даже пайшарм распознаёт на ура.

а чего больше: пользователей или каналов?

Примерно одинаково. Пускай это будет гипотетический пример. В задаче есть ещё свойства у каждой подписки и т.д и т.п.

ERROR: S client not available

Конкретно с namedtuple неудобно логику добавлять. Если логику добавить прямо в датакласс, то при использовании объекта непонятно когда он ходит в базу, а когда нет. Например, если user_foo.subscribe(channel_bar) ходит в эластиксерч, то почему user_foo.name не ходит? Или я что-то делаю не так?

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

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

Если честно, мне кажется, что докстринга это практически комментарий. Чтобы не делать такого появилась идея разделить данные и поведение. Но вот Фаулер пишет, что антипаттерн. а с получением одного поля не так однозначно. Например, user_foo.name = 'Bob' тоже получается ходит в эластик, а user_foo.subscriptions ходит или нет?

Если честно, мне кажется, что докстринга это практически комментарий. Чтобы не делать такого появилась идея разделить данные и поведение. Но вот Фаулер пишет, что антипаттерн. а с получением одного поля не так однозначно. Например, user_foo.name = 'Bob' тоже получается ходит в эластик, а user_foo.subscriptions ходит или нет?

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

Не хочется делать свой ORM к эластику. Хочется как можно проще :)

Не хочется делать свой ORM к эластику. Хочется как можно проще :)

Имхо проще - это плясать от конкретных юз-кейсов и тащить данные сразу там, где они заведомо понадобятся, и не тащить там, где хз. И писать докстринги ?

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

Конкретно с namedtuple неудобно логику добавлять. Если логику добавить прямо в датакласс, то при использовании объекта непонятно когда он ходит в базу, а когда нет. Например, если user_foo.subscribe(channel_bar) ходит в эластиксерч, то почему user_foo.name не ходит? Или я что-то делаю не так?

с новыми namedtuple из typing удобно

Вот. Вопрос хорошо ли это. Фаулер пишет, что это возвращение от ООП к процедурам

ну, это вопрос организации кода. Ты можешь сделать и класс User, но инициализировать его инстансом user_data, причем последний валидирует сырые данные, которые в него кормят при загрузке из внешнего хранилища

class MyBrandNewNamedTuple(namedtuple('MyBrandNewNamedTuple', ('brand', 'weight', 'color')): pass Такую конструкцию даже пайшарм распознаёт на ура.

namedtuple не нужен от слова совсем, после появления attrs, а тем более dataclasses

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

и это в джанге ужасно

Имхо проще - это плясать от конкретных юз-кейсов и тащить данные сразу там, где они заведомо понадобятся, и не тащить там, где хз. И писать докстринги ?

а потом докстринги не обновит кто-то и привет. документация, кроме пользователской, вообще не нужна, если код понятно написан:)

а потом докстринги не обновит кто-то и привет. документация, кроме пользователской, вообще не нужна, если код понятно написан:)

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

и это в джанге ужасно

А где лучше?

А где лучше?

в хорошо написанном коде;) можно и джанге писать так, чтобы name = obj.get_name() не ходило в базу никогда, потому что там для этого есть менеджеры моделей должно быть так obj = Obj.objects.with_names().first() name = obj.name

в хорошо написанном коде;) можно и джанге писать так, чтобы name = obj.get_name() не ходило в базу никогда, потому что там для этого есть менеджеры моделей должно быть так obj = Obj.objects.with_names().first() name = obj.name

Не, так за простыми полями объекта она, насколько помню, никогда не ходит. Оно может ходить или не ходить за foreign key и many-to-many. Там был какой-то волшбный параметр, который одним джойном вытаскивает сразу все связанные объекты.

в хорошо написанном коде;) можно и джанге писать так, чтобы name = obj.get_name() не ходило в базу никогда, потому что там для этого есть менеджеры моделей должно быть так obj = Obj.objects.with_names().first() name = obj.name

да и вообще, даже неявный вызов save() внутри методов - зло. обычно для этого делают как-то так obj.update_name("foo", save=True) причем, по умолчанию save=False

namedtuple не нужен от слова совсем, после появления attrs, а тем более dataclasses

dataclasses не поддерживают __slots__ и там иммутабельность сделана просто проверкой флага

dataclasses не поддерживают __slots__ и там иммутабельность сделана просто проверкой флага

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

Я к тому, что если нужен иммутабельный, то namedtuple полегче будет

namedtuple удобен если у тебя и правда таплы везде

namedtuple удобно возвращать из функции, например

Я к тому, что если нужен иммутабельный, то namedtuple полегче будет

ага, когда это станет узким местом, можно взять namedtuple :)

namedtuple удобно возвращать из функции, например

настолько же, как инстанс attrs класса

а потом докстринги не обновит кто-то и привет. документация, кроме пользователской, вообще не нужна, если код понятно написан:)

Кстати, интересно, есть ли приблуда, которая по git diff выдаёт варнинги, мол, ты метод поправил, а докстринг не изменился, пойди проверь.

Кстати, интересно, есть ли приблуда, которая по git diff выдаёт варнинги, мол, ты метод поправил, а докстринг не изменился, пойди проверь.

Для входных параметров и return ide же проверяют

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

Для входных параметров и return ide же проверяют

Не, я именно про человекочитаемую часть докстринга. Для профилактики ситуаций, когда логика в коде изменилась, а текстовое описание этой логики - нет. Хотя и изменившийся список параметров это тоже должно отлаливать, да.

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

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

Ругаться

Не, я именно про человекочитаемую часть докстринга. Для профилактики ситуаций, когда логика в коде изменилась, а текстовое описание этой логики - нет. Хотя и изменившийся список параметров это тоже должно отлаливать, да.

Детектить, что текстовое описание логики не изменилось - это уже что-то из разряда сильного ИИ :))