okfn/openspending.etl — comment on commit 4fbca891b4856069359d6daed8ddf6255dd42335
File: etl/importer/base.py line 3
By nickstenning:

I take your point. But what I'm saying is *not* that we should only import colander's `Invalid` through the `validation` module, but rather than the validation module should present its *own* exception type that we catch. In this particular case, we can just pass through colander's `Invalid`, because it fits our purposes and has a good interface for iterating over errors.

The reason is simple: if in the future we reimplement validation and remove colander, we could easily write our own exception class that presented a `colander.Invalid`-like interface. If that's imported as `validation.Invalid` then we would probably only need to change code in the `validation` module, whereas if it's imported as `colander.Invalid` then you need to change everything that depends on it, too.

Does that make sense?