Python-сообщество

Добрый день всем.

Возможно, кто-то уже читал про этот небольшой проектик на хабре https://habrahabr.ru/post/263821/. В любом случае, кому-то эта библиотека оказаться весьма полезной.
Страница проекта на гитхабе - https://github.com/Nepherhotep/django-orm-sugar

Для ленивых - библиотека добавляет синтаксического сахара (по сути - питоновского синтаксиса) при создании запросов через джанговскую ORM. Используя ее, вместо underscored синтаксиса

>>> SomeModel.objects.filter(user__profile__common_bucket__seq_count__gte=7)

>>> SomeModel.objects.filter(Q.user.profile.common_bucket.seq_count >= 7)

>>> Q.user.age < 7
Q(user__age__lt=7)

>>> Q(user__age__lt=7)
Q(user__age__lt=7)

>>> Q.data.owner.other_pets[0].name='Fishy'
Q(data__owner__other_pets__0__name='Fishy')
>>> Q.tags[0] == 'thoughts'
Q(tags__0='thoughts')
>>> Q.tags[0:2].contains(['thoughts']) 
Q(tags__0_2__contains=['thoughts'])

Сколько сахара в говно не добавляй - лучше оно от этого не станет.

ayb
Сколько сахара в говно не добавляй - лучше оно от этого не станет.

ZAN
И правдиво

Отредактировано 4kpt_IV (Март 17, 2016 13:36:04)

ayb
4kpt_IV
Отставить холиварные высказывания в данном топике.
:)

Ну так а в чем смысл библиотеки ? Зачем она нужна. Кто ей будет пользоваться ? Какой профит от ее использования ?

ayb для дальнейшей с вами дискуссии не самое было удачное начало

ayb
смысл понятен - многих банально раздражает система нижних подчеркиваний, тут же библиотека приводит к привычному виду тривиальные действия.
Вот кто это будет пользовать - вот тут согласен. Возможно это разработчикам Django показать надо =)

ZAN
для дальнейшей с вами дискуссии не самое было удачное начало

JOHN_16
смысл понятен - многих банально раздражает система нижних подчеркиваний

JOHN_16
У подхода с подчеркиваниями есть следующие проблемы:
главная проблема - нарушение принципа DRY. Если делается сложный запрос, то из-за того, что параметр передается, как keyword, его нельзя использовать заново (к примеру, если нужно сортировать по тому же полю). Проблема вторая - легко ошибиться с количеством подчеркиваний, особенно, если внутри самих полей есть подчеркивания. Третья проблема концептуальная - если я хочу отфильтровать поля, сравнивая со значением, то зачем использовать lookup expression “eq”, “gt” и т.д., если в питоне есть операторы? Ведь код - это своего рода история, если я хочу описать “больше или равно”, то в питоне есть для этого оператор “>=”, и по идее не нужно запоминать, какой lookup expression придумали разработчики джанги - “ge” или все-таки “gte”. Особенно это заметно для последних нововведений - сравнение, используя индексы или срезы - Q(tags__0_3__contains=) выглядит не очень презентабельно. Ни подсветка синтаксиса, ни мой внутренний парсер питона не умеет определять такие конструкции сходу, что усложняет чтение кода.
Касательно того, кто это будет использовать - да кто угодно, кто согласен с моими аргументами.
На счет разработчиков джанги - да, я обсуждал это в группе. Там захотели более общий подход, а не просто конвертация запроса в Q объект. Дело в том, что в джанге идет уход от кейвордов к созданию объектов, определяющих SQL запрос (примеры - относительно новый Expression API, Prefetch объекты и т.д.). Для внедрения полноценного синтаксиса от Django ORM Sugar, нужно реализовать поддержку методом filter специального класса (один из вариантов - класса, поддерживающего Expression API). Тогда бы вместо filter(username='Вася'), можно будет передать спец объект filter(Exact('username', ‘Вася’)). Вся хитрость в том, что такие объекты можно будет легко генерировать динамически подобно тому, как это сделано в Django ORM Sugar. Разница, возможно, не такая уж и большая, однако такой подход сделает Django ORM:
1. Более гибким - можно будет делать запросы, для каких вообще не существует соответствующих lookup expressions
2. Более простым, т.к. уже на данный момент код, разбирающий keywords на поля и lookup expression довольно сложен.
У меня была попытка сделать пул реквест, но никак не получалось решить один очень хитрый тест кейс, связанный с .exclude() вызовом, если в нем фильтруются ForeignKey. В принципе, может я его и доработаю когда-нибудь, но сейчас руки до этого не доходят.