Allow to pass a custom subclass of CallbackContext to Updater/Dispatcher that will be used instead of CallbackContext. We should document CC.from_*() for that.

This subclass should act as the initializer for every library-generated CallbackContext. Maybe edit that in :)

Hi @Bibo-Joshi .
I am new here and would like to contribute. I have set up python-telegram-bot repository locally as mentioned in CONTRIBUTING.rst and have gone through telegram.ext.Handler
I would like to get more information on the CallbackContext and the customization you have mentioned. Can you give me some pointers to start with?

more information on the CallbackContext

There are the docs, and there is the code. If you check both out (they are tightly integrated anyway), you should be good to go.

We cant really help you unless you ask a specific technical question :)

I think what @Poolitzer is trying to say is that tackling this issue should probably be done by someone who is familiar with the latest releases at least from a user point of view and it might be a bit much for a first time contribution. Ofc that depends on your motivation ;)

@Bibo-Joshi as per discussion on the PTB telegram group: I mentioned the possibility of replacing

if not isinstance(self.user_data, defaultdict)`  # & friends

with

if not isinstance(self.user_data, collections.abc.Mapping)`  # & friends

Are there any specific downsides with this? You're right, it "implies that we're supporting custom stuff, but that would not yet been properly implemented and tested", however I've grepped through the sources and couldn't find any places that rely on user_data/chat_data/bot_data being a defaultdict specifically. Even more, this will be backwards-compatible since people using both built-in or custom persistence classes will still be using those same defaultdicts that are constructed in current persistence implementations, but will be able to implement a broader scope of persistences by walking away from being forced to return defaultdict.

And we can still implement & test this :)

Hey. Maybe I didn't properly explain myself or we talked past each other.
What I meant was rather that a one-line PR would not do justice to the matter. It's correct that the checks in Dispatcher around that line are the main thing to be changed in the code to allow BP.get_* to return custom stuff, but it would also need proper documentation (at least in BasePersistence, probably also on the wiki page on persistence), type hinting and testing (of the custom return stuff in BP, of the integration with Dispatcher and CallbackContext and for conversations also with ConversationHandler). If you're up for that: you're very welcome to! My point was that this is not a project for half an hour ;)
But a PR for customizing BP.get_* can indeed be independent from a PR allowing for custom CallbackContext subclasses …

PS: Please delete one of your replies - having the same comment twice does not add any value to the discussion ;)

closed by #2262