Arun Mani J

1. Context can be taken as a channel for intraprocess communication.
2. Classes are quite rigid in structure and by the definition, they must have same layout throughout the program.
   That is, dynamically adding and removing attributes is a very bad design.
3. Dictionary, it is. They are designed to dynamically updated and so context uses dict.
4. But as it is, context is very flexible in mapping any immutable object to any.
5. I don't understand how context can be replaced by classes without polluting pureness of Telegram objects. That is, there is context.args to get args of a command, if we move this to Message.args, then there will be a very big conflict between Telegram bot spec and ours.

This confuses users more. Context style message passing is also available in Flask. We are providing a built in solution to avoid boilerplate messy code on users side

David Shiko

Context is a great feature, but overkill in most cases.

2. In my code, I always declare all the attributes in the initialization method, in most cases it is None
3. In my opinion, using self.user.name instead of context.user_data ['user']. Name is much more readable (assigning user = context.user_data ['user'] looks funny.
4. I do not mean replacing the context, but the optional use of a class instead of a context.

Me

Context is a great feature, but overkill in most cases.

sure, you'll probably not need many of the attributes for many callbacks. but it comes at almost zero cost to have them. The alternative would be to go back to v11 style callbacks def callback(bot, update, user_data, bot_data, …) and all the pass_* arguments for the Handlers.
always passing a single context argument from which you can choose to use or not to use something just makes the interface more consistent and less bloated.

user = context.user_data ['user'] looks funny.

Via ext.ContextTypes you can make user_data a custom class such that you can write context.user_data.data if that's more to your liking.

I do not mean replacing the context, but the optional use of a class instead of a context.

I don't really understand this point. context is an instance of a class. implementing all your callbacks as methods of a custom class is ofc fine, but that has little to do with whether or not context should be passed to those methods

David Shiko

The additional advantage of classes before function is structuring.
By classes you can bind multiple CH handlers into one logic structure.
So that's good way to distinguish between command (and other) handlers and CH handlers.

I mean 2 things:

1. Putting handlers directly in states dict it's a messing between logic and implementation. So between menu and user defined handlers of states should be some interface.
2. List of handlers for state instead of single handler is making a messy. Every state should have only one entry point.

Me

1. Putting handlers directly in states dict it's a messing between logic and implementation. So between menu and user defined handlers of states should be some interface.

I can't follow you here. what exactly do you mean by "logic", "implementation" and "menu"?

2. List of handlers for state instead of single handler is making a messy. Every state should have only one entry point.

I'd argue that having multiple handlers for a state can be useful, e.g. if in a state you want to be able to handle both messages and callback queries. But you don't have to pass mutliple states. Ofc chaning CH such that it can accept a single handlers instead of [handler] is something that we can discuss :)

The additional advantage of classes before function is structuring.

Then I'd go back to my argument from #2802 (reply in thread) :)

Me

I don't understand what point you're trying to make here. What's the punshline of this message?

what do you mean when you say "menu"? CH can do much more than just offer options to choose from in each step. At the very core, CH is a finite state machine

(https://en.wikipedia.org/wiki/Finite-state_machine)> when the purpose is definition rather than execution
I disagree. CH is a handler and it's purpose it to execute stuff.

Menu should be separated from either internal logic and calls of bot methods.

what do you mean by "internal logic"? internals of PTB? internals of CH? internals of your code?

Me

what I see here is mostly "abstracting your callbacks into a custom class". THat's ofc fine if it helps you keeping your code structured, but I don't see a necessity to enforce this pattern.

From what I understand bound_class=User2 is supposed to mean that for each conversation, an instance of this class is created? You can achieve the same effect by doing something like

def callback(update, context):
    # using a custom `CallbackContext` class
    obj = context.conversation_objects(update)
    obj.callback(update(, context))

I don't fully understand what the defaults, menu and failed kwargs are supposed to be there for … could you elaborate?

David Shiko

Yes.
defaults, menu, failed it's are synonym for rpefallbacks, states, fallbacks, don't focus on it.