MySQLdb exceptions should reflect their public API name in tracebacks

[metzen]

Currently, the exception types used by MySQLdb are defined within the MySQLdb._exceptions submodule, but are also aliased as symbols within the MySQLdb._mysql C extension module, as well as imported from there to be exposed in the top level MySQLdb package, where they are intended to be used by clients.

However, when one of these exceptions is raised by the MySQLdb implementation, the name which is depicted in the resulting traceback will reference the original definition location of the exception in MySQLdb._exceptions, e.g.,

MySQLdb._exceptions.ProgrammingError: (1064, "You have an error in your SQL syntax ...")

When users encounter such an error, they may be inclined to use the name as it is depicted in the traceback when attempting to add exception catching behavior for the error rather than the intended public alias in MySQLdb.ProgrammingError (if they are not aware that this is provided).

It would be prudent to steer users in the right direction by avoiding this private submodule exposure and having the name used in tracebacks reflect the intended public interface for referencing the symbol.

[metzen]

I see a couple of options for achieving this:

1. Define the exceptions in the top level MySQLdb/__init__.py file itself.
2. Define a __module__ = 'MySQLdb' attribute for each exception type declared in MySQLdb._exceptions

The first is the most obvious, but I suspect the motivation for having the exceptions defined in the separate module was to avoid circular import issues given that the exceptions are imported by the _mysql.c C extension, which is itself imported in the top level __init__.py package?

If that's the case, then simply overriding the __module__ attribute of these exception classes could be used to let them reflect the public interface for referencing them, regardless of their actual definition being in the _exceptions submodule.

[methane]

Thank you. You are completely right.