Remove unused error aliases by assignment

[Avasam]

Just like #2268 , this doesn't focus on a fix for #1902 yet.

These are the aliases that are easy to remove because they are unused and/or simple aliases.

Now the question is:

These are not exceptions we expect to actually hit or have people catch [...]

Should they still be accessible with a deprecation warning ? Or is it ok to remove them?

[mhammond]

I think we should soften this message a little - IIUC we don't expect any breakage here because strings as exceptions simply don't work, but a quick read implies something like "if you were catching these exceptions, here are the new names you should catch"

For public symbols which were actually errors I see no reason to stop exporting them.

[Avasam]

Certainly! I'll think how I wanna reword this.

[mhammond]

I see no reason at all to stop exporting this - it seems perfectly reasonable people would use this module directly and catch this error directly. Ditto for the others which are similar.

[Avasam]

I guess this is re-exporting pywintypes.error in case someone wants to use the win32evtlogutil module without having to import pywintypes directly.

I do have some questions though, and a bit of concern about user confusion. Which I've heavily felt when starting to use pywin32 (it's what kickstarted this whole annotations and stubs thing ^^"). Relevant here is trying to understand what's a re-export vs a different Exception class, where one should import from vs a leaked import, etc... Having a bunch of same-named aliases error for different exception types pywintypes.error, com_error, TLBrowserException doesn't help either (and can easily lead to accidental shadowing).

Does com/win32com/universal.py really share that concern as modules in Lib ? If so, why aren't all other modules that can raise uncaught com_error or COMException also re-exporting them?

What about error = RuntimeError in win32/Lib/win32serviceutil.py though? I really don't see the point of that one. If you wanna catch RuntimeError just use RuntimeError no? Is it promising that absolutely no other exception types can bubble up ?

If it was its own exception class that can be differentiated that would make sense, but as a direct alias I'm not so sure.

[mhammond]

There are 2 questions here I think:

• Should, eg, win32serviceutil have re-exported RuntimeError as win32serviceutil.error - that's an interesting question and I'm really not sure of the answer. I think that a module like the above should be clear about what exceptions it throws so consumers know what to catch, and I think that:

try:
  win32serviceutil.something()
except win32serviceutil.error:
 ...

is an improvement over catching RuntimeError. Maybe it should not have been an alias and instead should have been a real exception subclass? Maybe it should have been a different alias? Regardless of the answers to them, I think the code snippet above is clear.

• Is the more relevant question here though: even if we agree that the above point was a historical mistake, was it bad enough we want to break existing code? IMO, the answer to this is a resounding "no".

[Avasam]

Updated! And added a comment clarifying that a re-export is definitely the intent.