One thought before i proceed with the rest of the classes.

Both attributes and arguments should only accept timedeltas in the long run.#4575 (comment)

why deprecate class args, i think it would be convenient to allow passing either30 ortimedelta(seconds=30). it would also be consistent with how bot methods work as of#4651. deprecating class attrs is sensible however.

Hey, thanks for getting started so quickly:)
About your question: TelegramObject types are not really intended to be manually initialized by the user but rather by the de_json methods - that's in contrast to the bot methods. I view them as mere data storages. Note that the conversions from json to datetime or off of the TG classes also all happen in de_json and not in init. This approach can certainly be questioned in general (i.e. what would be a sensible interface for classes wrapping API types). In the current set-up, I'd see consistency as the more important argument 😅

Aha okay. but would it still be necessary to issue a separate deprecation warning in the init methods as was outlined in#4575 (comment) (very helpful summary btw 😄 ). one is already being issued on property access.

I would say, so yes. Attribute access and passing the parameter are two independent operations, both of which will be affected :)

I see! I was thinking more from the perspective that

TelegramObject types are not really intended to be manually initialized by the user rather by the de_json.

whom are we intending to warn then

anyways I did include both warnings for completeness and the cases where users are manually initializing objects

Almost ready for a review. just a few things to discuss.

• Not sure if I should follow the deprecation process for fieldResponseParameter.retry_after which maps to PTB's classRetryAfter(TelegramError). a suggestion is to letself.retry_after continue being andint. and only alter the message of the error with a timedelta value derived fromselr.retry_after. So it prints:
  Flood control exceeded. Retry in 0:08:20.
  instead of what it currently prints:
  Flood control exceeded. Retry in 500 seconds
  Reason being that it's underlingint type is not user-facing. and also not to break older pickles of the class.
• Automatic detection of time periods in test_official works great (only needed a few adjustments). Anyway it also detectedBot.get_updates.timeout (getUpdates) which i think was missed in#4651 (?). I have currently adjustedBot.get_updates.timeout but without altering the signature of other methods that call it (i.eUpdater.[_]start_polling) which also have atimeout parameter.

Checks are really mad, will debug tomorrow :')

Hey, thanks for the updates - looks like you've spend quite some energy in this, awesome :) I haven't managed to look at the code yet, so at least giving my 2cts on your comments

• RetryAfter: I'd personally also like a timedelta here, nice catch actually! In terms on interface changes I don't see a reason not to do that. If updating the pickle behavior becomes difficult I'd be okay with staying with an integer. Mind that pickle behavior doesn't need to be backward compatibile - we explicitly exclude that in the stability policy and I guess picklung exceptions is a rather small use case …
• thanks for also catchingget_updates. Even though I'm not quite sure why I skipped it, I think it may be because I also skipped all the other timeout parameters. Accepting timedelta for them as well might make sense as well but here the issue would be that the abstractBaseRquest.do_request should then also broaden the signature. So I'd postpones that discussion for now. forget_updates.timeout I'd say you can feel free to update also the signatures that forward the value toget_updates.timeout :)