Нормально ли создавать такой класс чтоб вычислять разницу дат или

деттаймов в целых днях, насколько я уместно применил магические меттоды и датакласс?
@dataclasses.dataclass
class DateFrameBound:
"""
Class to represent a bound for a date frame based on specific date.

Whether to include the day of a bound in an interval is specified
"""

bound: date
including: bool

def __lt__(self, other):
if not isinstance(other, DateFrameBound):
return NotImplemented
return self.bound < other.bound

def __sub__(self, other) -> timedelta:
if not isinstance(other, DateFrameBound):
return NotImplemented
days_delta = (self.bound - other.bound + timedelta(days=self.including + other.including - 1)).days
return timedelta(days=days_delta)

ChatGPT: Да, такие классы можно создавать и использовать для вычисления разницы дат и деттаймов в целых днях. Вы действительно можете применить магические методы и датакласс хорошо, поскольку это позволит вам создавать удобные и читаемые для работы с датами и деттаймами. Однако, я хотел бы подчеркнуть, что лучше всего использовать временные шкалы, такие как ISO 8601, для более эффективного и легко читаемого кода. Эта система времени позволяет создавать простые и гибкие срезы для дат и деттаймов, а также обеспечивать согласованность между различными системами, основанными на временных шкалах. 🤔

@cutwater неумесное использование chatgpt + паста

Его использование никогда не уместно

в данном случае точно

RO 1d, ISO 8601 - это формат представления, к качеству кода не имеет отношения.

Что за bound и including и что они делают в атрибутах класса. Остальные операции просто пропущены или задумано так и оставить? И в чём смысл вообще?

ю

Они не нужны. Bound граница - поскольку это границы ренжа считай. А инклудинг, это включительный, как с математики включительный или нет. От этого зависит надо ли добавлять день границы в промежуток или нет . Условно говоря > и >=

Что значит "не нужны"? Параметры объекта инициализируются в ините объекта, а не класса.

Как вообще можно нейминги поменять чтоб было более понятно

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

А как без нее работать? Нет норм способа так отнимать дни

Обычными таймдельтами.

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

У меня кейс такой - юзер задаёт рендж из двух дат. Может юзать > , >= , Надо вы́числить разницу в целых днях. Для этого кейса норм?

Я б для рейнжа целиком делал, а не для каждой границы отдельно.

Ну так этот рендж надо ещё задать в зависимости от границ. Границы там вычисляются многими условиями if .... start_bound = DateFrameBound().. elif .... start_bound = ... И тд

Думаю прислушаться к твоему совету ,как-то так сделать, класс дейт рендж с такими атрибутами start_bound: date include_start_day: bool end_bound: date include_end_day: bool