We currenty have clauses like
|
if data is None: |
|
return None |
and
These sometimes make difficulties for classes that have no required arguments such that {} is valid input for de_json. Moreover, classes with subclasses (BotCommandScope & sim), where de_json calls the de_json method of a subclass, need to take care of this as well.
AFAIK the main use case for the emtyp-data handling is calling other classes de_json. E.g. Update.de_json calls
data["message"] = Message.de_json(data.get("message"), bot)
and data.get("message") might be None.
Neither TO.de_json nor TO.de_list documents how empty data ({}) or None is handled. Note that the type hints do give something away, but they are explicitly excluded from our stability policy.
To simplify internal logic, I propose to
- switch to uniform
if data is None: return None
- optionally even remove that and think of a clean way to handle the
Message.de_json(data.get("message"), bot) case
We currenty have clauses like
python-telegram-bot/telegram/_telegramobject.py
Lines 394 to 395 in 2ac5201
and
python-telegram-bot/telegram/_telegramobject.py
Lines 462 to 463 in 2ac5201
These sometimes make difficulties for classes that have no required arguments such that
{}is valid input forde_json. Moreover, classes with subclasses (BotCommandScope& sim), wherede_jsoncalls thede_jsonmethod of a subclass, need to take care of this as well.AFAIK the main use case for the emtyp-data handling is calling other classes
de_json. E.g.Update.de_jsoncallsand
data.get("message")might beNone.Neither
TO.de_jsonnorTO.de_listdocuments how empty data ({}) orNoneis handled. Note that the type hints do give something away, but they are explicitly excluded from our stability policy.To simplify internal logic, I propose to
if data is None: return NoneMessage.de_json(data.get("message"), bot)case