1. I put __repr__ methods right after __init__, but for Job I put it in the end because that's where __eq__ and __hash__ were.
2. Maybe I should add angular brackets to make output look like automatic __repr__
3. Not sure how I can access the whole schedule from Job. I can only access the time of next job execution, I think.

1. I put __repr__ methods right after __init__, but for Job I put it in the end because that's where __eq__ and __hash__ were.

I actually highly prefer having magic methods in the beginning of a class, since they define the behaviour of a class. Don't know why none of the linters support such a thing. Let's make a new issue to do this if everyone thinks the same.

1. I put __repr__ methods right after __init__, but for Job I put it in the end because that's where __eq__ and __hash__ were.

I actually highly prefer having magic methods in the beginning of a class, since they define the behaviour of a class. Don't know why none of the linters support such a thing. Let's make a new issue to do this if everyone thinks the same.

I also like having all magic methods in one place. Since __init__ already is one, the start makes sense, but I'm also fine with the end usually … For this PR putting __repr__ after __init__ or where other magic methods already are sounds good 👍

2. Maybe I should add angular brackets to make output look like automatic __repr__

I don't see really the benefit of that …

3. Not sure how I can access the whole schedule from Job. I can only access the time of next job execution, I think.

shouldn't that be available as job.trigger?

I should create some tests for these methods, right?

note that for the TG classes which are mostly "data classes", the ClassName(…) repr still makes sense for me)

I don' think we ever planned to create __repr__ for Telegram classes though (i.e. subclasses of TelegramObject) 🤔 But maybe I should try this style for the other classes as well and see how it goes.

note that for the TG classes which are mostly "data classes", the ClassName(…) repr still makes sense for me)

I don' think we ever planned to create __repr__ for Telegram classes though (i.e. subclasses of TelegramObject) 🤔 But maybe I should try this style for the other classes as well and see how it goes.

Sure we did:

• Readable string representations for TelegramObject #3234
• https://docs.python-telegram-bot.org/en/stable/telegram.telegramobject.html#telegram.TelegramObject.__repr__

Sure we did

OK, I was being inattentive and imprecise (need a third flaw to make a combo). But the point of my message was, "we're not doing anything to TO here in this PR" :) In your comment you were obviously referring to the existing practice, and I misunderstood it.

A downside is that it suggests that you can instantiate the object like that which is not always the case.

How about we write something like Application(param1=value1, param2=value2, ... ) - with an ellipsis to make it clear that these params are not enough to instantiate the application?

A downside is that it suggests that you can instantiate the object like that which is not always the case.

How about we write something like Application(param1=value1, param2=value2, ... ) - with an ellipsis to make it clear that these params are not enough to instantiate the application?

I'm not sure if that's much better. Thinking about it, e.g. for Jobs the trigger is actually not an argument that we directly pass to neither Job nor run_*, so showing it as kind of argument would be rather confusing, I guess 🤔

I was about to hit merge - but then I remembered one more thing 🙈 For TelegramObject we documented all the dunder methods and for consistency I would vote to do the same here. However, the code change itself is already approved and I don't want to stretch this PR needlessly. We can do this as a follow-up PR. @lemontree210 please let me now what you prefer

For TelegramObject we documented all the dunder methods and for consistency I would vote to do the same here.

consistency is key! :)

DS failure unrelated - see #3888. Merging.

PS: Will open a follow-up issue on #3826 (comment)

PPS: I'm blind - that was already addressed