[Python-ideas] Possible enhancement to typing

[Steve Barnes]

On 06/11/2017 07:13, Steven D'Aprano wrote:
> 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.
> 
Good point.
> 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.)
> 
I see your point here.

> See here for further discussion:
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fimport-that.dreamwidth.org%2F676.html&data=02%7C01%7Cgadgetsteve%40live.co.uk%7C5e419db490b84018f2d208d524e612b4%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636455492928665911&sdata=EFZIvxGxO18vk5s97RnSHH9kAuLS3sXBxDNS9VbLWlw%3D&reserved=0
> 
> 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'll have to look out 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.
> 
> 

Too much time spent writing safety critical code on my part then! I'll 
drop the idea.
-- 
Steve (Gadget) Barnes
Any opinions in this message are my personal opinions and do not reflect 
those of my employer.

---
This email has been checked for viruses by AVG.
http://www.avg.com