refactor!: remove all unwanted __repr__ and __str__

[EepyElvyra]

About

This pull request removes the __repr__ and __str__ so they do not override the attrs repr

Checklist

• The pre-commit code linter has been run over all edited files to ensure the code is linted.
• I've ensured the change(s) work on 3.8.6 and higher.

I've made this pull request: (check all that apply)

• For the documentation
• To add a new feature
• As a general enhancement
• As a refactor of the library/the library's code
• To fix an existing bug
• To resolve [REQUEST] Remove or improve __repr__ and __str__ on models #1140

This is:

• A breaking change

[Catalyst4222]

What about emojis and users?
I think that the repr of the emoji is helpful, just in the wrong place. Could you make it a property instead?

[EepyElvyra]

What about emojis and users? I think that the repr of the emoji is helpful, just in the wrong place. Could you make it a property instead?

I don't see how making it a property is helpful? It is a very good thing that when you do "{emoji}" the emoji gets immediately converted to it's sendable form and I don't see a reason to change that

[Catalyst4222]

First, fstrings convert using __str__ in that case, and emojis have __repr__. Second, it shouldn't be too much effort for the user to use an attribute/property. Your alternative (adding the __str__ method) would slightly reduce typing for users using the fstring, but it can add confusing to devs printing out objects, which was the cause of the linked issue

[EepyElvyra]

First, fstrings convert using __str__ in that case, and emojis have __repr__. Second, it shouldn't be too much effort for the user to use an attribute/property. Your alternative (adding the __str__ method) would slightly reduce typing for users using the fstring, but it can add confusing to devs printing out objects, which was the cause of the linked issue

I have changed it to __str__. I understand the confusion as I encountered it myself, too. However I think in case of the emoji object this confusion is at a lower level. I have enabled the attrs repr so if any developers are still highly confused about the emoji object printout they can print(repr(emoji))

[Catalyst4222]

Many developers (including me) will print an object instead of the repr of the object, often because they're the same

What's the reason not to have it as a property?

[EepyElvyra]

Many developers (including me) will print an object instead of the repr of the object, often because they're the same

What's the reason not to have it as a property?

It is an unnecessary breaking change imo.

Also, in most cases you won't bother about the attributes of an emoji, would you? I'd assume mostly you just want to send it or create an reaction with it. I really thing having emojis like that is fine. If major complaints emerge, we still can change it at a later point.

[Catalyst4222]

A complain already has emerged, which was the reason behind the issue in the first place. Having the magic method just adds unexpected cases, while a property will only impact code when it's accessed intentionally. A property makes it more clear what code is doing, which __str__ does not