[Python-ideas] Possible enhancement to typing
Steven D'Aprano
steve at pearwood.info
Mon Nov 6 02:13:57 EST 2017
On Sun, Nov 05, 2017 at 07:18:30PM +0000, Steve Barnes wrote:
> If a group of iterators were to be added to the typing module it would
> be reasonably simple to automatically add and assert to any decorated
> modules to ensure that such modules were always called with the
> documented types.
"Iterators"?
> I am thinking of decorators such as:
>
> - @typing.assert_params_mismatch - this would provide a wrapper that
> had auto-generated asserts that all the parameters were of designated types.
> - @typing.debug_assert_params_mismatch - this would provide a wrapper
> that had auto-generated asserts that all the parameters were of
> designated types only if a DEBUG environmental variable was set or similar.
That's what assert does: assert only runs when __DEBUG__ is true. That's
not controlled by an environment variable, but by the -O flag to the
interpreter.
So your assert_params_mismatch and debug_assert_params_mismatch are
effectively the same thing.
But using assert to check to perform argument checks is often an abuse
of assert. To be more specific, using assert to check the value of
public arguments in library code (where the arguments come from outside the
library) is wrong, since you (the library author) cannot guarantee
that your type tests will even run.
Using asserts for argument checking inside application code is more of a
grey area, with arguments for and against using assert.
But in my opinion, the deciding factor is nearly always that an
AssertionError is the wrong sort of exception. Outside of some fairly
limited circumstances, most of which don't involve type-checking
function arguments, using assert robs the caller of some useful
information: the *kind* of error. (TypeError, ValueError, etc.)
See here for further discussion:
https://import-that.dreamwidth.org/676.html
In general, I don't think we want to encourage such runtime type
testing. Obviously there are exceptions -- library code should
probably type check arguments, applications perhaps not -- and
we're not exactly discouraging it either. There are already a number of
third-party libraries that provide argument type tests at runtime, and
I think that's probably the right place for them.
[...]
> I also think that this might increase the uptake of typing by giving
> some clear benefits outside of documentation and static type checking.
Problem is, the benefits of runtime type checking aren't clear. But the
costs certainly are: if you want slow code, do lots and lots of runtime
type checks.
--
Steve
More information about the Python-ideas
mailing list