Setting custom attributes on objects of the PTB library is deprecated?

[copy-plus-pasta-equals-love]

I have been using a custom attribute on the telegram.Bot instance for a long while. It's a large and major component of my bot usage.

Now I am seeing the TelegramDeprecationWarning that seems related to a recent PR #2345

There is no note about if or when this will go from a warning to a breaking change, and perhaps more importantly, what the reasoning is behind it.

I did read the comments on that PR, but it is not obvious to me why it should be a problem for users to enhance the bot in this way, nor how urgent it is for me to take action steps here, nor what those would be.

[zeroone2numeral2]

Quoting the v13.6 release post in the Telegram channel:

1️⃣ We added slots to (almost) all classes. Head here for detailed info about slots. TL;DR: At least in CPython slots can reduce memory usage and improve performance by fixing which attributes an objects has.

⚠️ For backward compatibility we made sure that code like update.message.my_custom_attribute = 42 will continue to work. However, as adding custom attributes to predefined objects is bad practice anyway, this will raise warnings and we will remove support for this at some point, maybe already in v14.

[copy-plus-pasta-equals-love]

Thanks. I have now subscribed to the telegram update channel

[Bibo-Joshi]

Hi. Thanks for reaching out.

We added __slots__ mostly for the benefits they can bring in terms of menory usage and performance. Disallowing users from adding custom attributes to PTB-classes in the future is more a side effect of this, but one that I support.

Dynamically adding attributes to classes is certainly a useful feature for some use cases in Python, one example being Handler.collect_additional_context in PTB, which encourages you to add custom attributes to a CallbackContext object (and this will ofc work in future versions).
However, there are also many cases were I'd argue that there is a cleaner solution. E.g. for the types defined by the Bot API, I'd argue that it's unnatural to add additional information b/c those objects are supposed to represent the info you get from the API. If you want to store additional information associated with them, do that e.g. in user/chat/bot_data. If you want to add custom behavior to the Bot class, you can subclass it. Not adding attributes dymically eliminates the chance of getting AttributeErrors at runtime and makes it easier to debug your code, because the error can only originate in a small number of places (in constract to almost everywhere in the code base).

I admit that I used something like update.effective_user.custo_attr = foo at one point myself, but even at that time it felt like a dirty hack and I only did it because I was too lazy to code a clean solution. To allow people to adjust, we added __dict__ to __slots__ so that we have e deprecation phase.

Regarding

There is no note about if or when this will go from a warning to a breaking change, and perhaps more importantly, what the reasoning is behind it.

As @zeroone2numeral2 already pointed out, we made a at least slightly more elaborate announcement on the news channel on Telegram. This is where we always post an overview for new releases, while the changelog in the docs and the GH releases only contain the pure changelog. I'll make sure to link to the release channel in the tchnical changelog for future releases.

We'll only remove __slots__ in v14, if the development phase of that version is long enough to argue that people had enough time to adjust for __slots__ - though my guess is that it will be, if I look at our line up for v14 😄

[copy-plus-pasta-equals-love]

Thanks. Looks like I have plenty of time to make adjustments.

[Poolitzer]

I would be interested in what are you setting in bot and if you can or can not achieve the same with bot_data.

[copy-plus-pasta-equals-love]

I'm pretty sure bot_data had not been implemented yet when I started. My attribute is fairly similar, just a bunch of in memory info that sometimes gets dumped out to a persistent place.

Thanks for pointing me in the right direction, I will be able to make that work.