Nikolay Chechulin:
Товарищи, встал вопрос.
Все мы знаем, что оверрайдить стандартные методы нехорошо
Тем не менее, вот есть у меня класс Post (пост в социальной сети). У него есть id, который, естественно, называется так же, как и встроенная функция питона. В Post.post_id переименовывать не комильфо.

Собираю мнения: простительно ли в этой ситуации заоверрайдить стандартный метод?

Это новый вид спама такой.
Я в шоке.

А что не нравится-то?
Норм.

Смотри:
from бла import Post
zopa=Post(тртртр)
print(zopa.post_id)
        ^^^ это объект и у него любое имя может быть и даже не ы его можешь придумать, а другой кодер.

agentsmith6969: Nikolay Chechulin: ну id и что-то.id не совсем то же самое

agentsmith6969: ага, а если есть уже база с таблицами, и там менять надо если работа напрямую а не через какой-нибудь умный ORM который сам это сделает, и SQL запросы менять везде надо

Друзья! Наше сообщество строится вокруг Python и всего, что с ним связано. Мы рады всем, кто хочет развиваться и помогать другим.
Думаю, большинство из вас здесь именно для этого, но в последние дни несколько участников явно перешли границы приличия. Я лично не хочу никого банить, надеюсь на общую сознательность, здесь все взрослые люди.

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

🔥

Всем привет! Давно интересует вопрос как правильно ловить и возвращать ошибки. Я пишу апишку и бывают "легитимные" ошибки вроде "пользователь не найден" или "нужна авторизация".
Я знаю 2 варианта:
1. Оберрнуть все в try / except Exception as e (для неожиданных ошибок) и все легитимные ошибки возвращать через return
2. Райзить исключения фреймворка и их же ловить (что бы они НЕ попадали в "неожиданные ошибки и не логировались".

Пример вар. 1:

try:
    if not user:
        return framework_error_obj(text='user not found error')
except Exception as e:
    # log error
    raise framework_error_obj(text='status code 503, service unavailable')

Пример вар. 2:

try:
    if not user:
        raise framework_error_obj(text='user not found error')
except framework_error_obj(error='user not found error'):
    pass
except Exception as e:
    # log error
    raise Exception('status code 503, service unavailable')

try:
    if not user:
        return framework_error_obj(text='user not found error')
except Exception as e:
    # log error
    raise framework_error_obj(text='status code 503, service unavailable')

try:
    if not user:
        raise framework_error_obj(text='user not found error')
except framework_error_obj(error='user not found error'):
    pass
except Exception as e:
    # log error
    raise Exception('status code 503, service unavailable')

Ловите те исключения, которые ожидаете. Остальные вывалятся наружу, не пропустите.. )

Вообще, я не очень понял вопрос.

++

ты спрашиваешь какой из вариантов лучше?

Я подредактировал вопрос, добавил там "НЕ" капсом, где пропустил его.
Вопрос стоит так: как внутри try блока поднимать исключения так, что бы они не попали в except блок.Сейчас  я их просто возвращаю через return, но не знаю, хороший ли это подход

Да

первый

но если ты рэйзишь одно и то же дважды то значит надо создавать свои exception (типа raise UserNotFoundException)

ну и тут вопрос странный

exception на уровне сериализации валидациии и тд

а первый вариант это уже вьюхи

если где-то ошибся исправьте, пж