Bug #89480 Reconstructing mysql Error from its __repr__ causes attribute error

Description:
The base mysql connector python exception class (https://github.com/mysql/mysql-connector-python/blob/master/lib/mysql/connector/errors.py#...) overrides self.args. 

the default __repr__() method relies uses self.args and therefore in this case does not return a consistent representation of the object. 
From the python docs on __repr__ () "built-in function to compute the “official” string representation of an object. If at all possible, this should look like a valid Python expression that could be used to recreate an object with the same value". Because self.args the reordering of self.args is not type compatible calling eval() on any exceptions repr fails due to an attribute error.

current constructor: `__init__(self, msg=None, errno=None, values=None, sqlstate=None)`
args overriden `self.args = (self.errno, self._full_msg, self.sqlstate)`

How to repeat:
```
>>> from lib.mysql.connector.errors import Error
 
>>> err = Error('MSG', -1, 'VALUES', 'SQLSTATE')
>>> eval(err.__repr__())
Traceback (most recent call last):
  File "test.py", line 5, in <module>
    eval(err.__repr__())
  File "<string>", line 1, in <module>
  File "/Users/andrewwright/work/mysql-connector-python/lib/mysql/connector/errors.py", line 194, in __init__
    'msg': self.msg.encode('utf8') if PY2 else self.msg
AttributeError: 'int' object has no attribute 'encode'
```

Suggested fix:
EIther a custom __repr__() method should be defined, or self.args should not be overridden, especially with a different ordering to the calling function.

If a custom display of the object is really needed it should use __str__ or a custom method.

Happy to make a PR for this one, just want to check the best approach. As far as I can tell there is no reason to override self.args in the first place but I may be missing something.

Hello Andrew Wright,

Thank you for the bug report.
Verified as described with the help of dev's.

Thanks,
Chiranjeevi.

Posted by developer:
 
This issue was fixed by WL#14239 in release 8.0.24. Thank you for the bug report.

Posted by developer:
 
Note: this problem was eliminated in 8.0.24 when Python 2.7 was removed; thank you for the bug report, status->closed.