Message266391
The reason we specifically omitted Error was two-fold:
- the name "Error" is very generic and during a star-import might easily shadow some other class of the same name;
- Error is only a base class for exceptions raised by configparser and as such isn't part of the public API. You can see the same behavior in concurrent.futures for example. However, now I noticed configparser.Error is listed in the documentation so the assertion that "it's not public API" is effectively incorrect.
So I'm torn a little here. On the one hand, it's nice to add Error for completeness. On the other hand, is this change solving a real issue or just satisfying your inner librarian? The reason we have to ask ourselves this question is that this change bears a small risk of breaking user code that was working before. Take a look at this example:
```
from wave import *
from configparser import *
cfg = ConfigParser()
cfg.read('appconfig.ini')
try:
with Wave_read(cfg['samples']['sad_trombone']) as wav:
n = wav.getnframes()
frames = wav.readframes(n)
except Error as e:
print("Invalid sample:", e)
except KeyError as e:
print("Can't find {!r} in the config".format(str(e)))
else:
play_sound(frames)
```
Sure, it's bad code but the point is: it was working before and had a decent error handling strategy. With the change in __all__, it will just crash because wave.Error was never caught.
Is this likely to happen? I don't think so. Knowing my luck, will it happen to somebody? Yeah. So the question remains: why do we want Error in __all__ in the first place? Is it worth it? |
|
Date |
User |
Action |
Args |
2016-05-25 19:52:56 | lukasz.langa | set | recipients:
+ lukasz.langa, martin.panter, Unit03 |
2016-05-25 19:52:56 | lukasz.langa | set | messageid: <1464205976.79.0.780709892671.issue27106@psf.upfronthosting.co.za> |
2016-05-25 19:52:56 | lukasz.langa | link | issue27106 messages |
2016-05-25 19:52:56 | lukasz.langa | create | |
|