Proposal: add an "ensure(arg)" builtin for parameter validation

[ncoghlan]

BPO	32590
Nosy	@brettcannon, @ncoghlan, @stevendaprano, @bitdancer, @xgid, @smarie

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2018-01-23.00:19:44.901>
created_at = <Date 2018-01-18.05:32:11.650>
labels = ['type-feature']
title = 'Proposal: add an "ensure(arg)" builtin for parameter validation'
updated_at = <Date 2018-02-02.02:40:26.568>
user = 'https://github.com/ncoghlan'

bugs.python.org fields:

activity = <Date 2018-02-02.02:40:26.568>
actor = 'xgdomingo'
assignee = 'none'
closed = True
closed_date = <Date 2018-01-23.00:19:44.901>
closer = 'ncoghlan'
components = []
creation = <Date 2018-01-18.05:32:11.650>
creator = 'ncoghlan'
dependencies = []
files = []
hgrepos = []
issue_num = 32590
keywords = []
message_count = 7.0
messages = ['310219', '310225', '310231', '310243', '310255', '310280', '310453']
nosy_count = 6.0
nosy_names = ['brett.cannon', 'ncoghlan', 'steven.daprano', 'r.david.murray', 'xgdomingo', 'smarie']
pr_nums = []
priority = 'normal'
resolution = 'postponed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue32590'
versions = []

[ncoghlan]

This proposal is an outcome of repeated requests on python-ideas that assert statements be made unconditional, so they can be legitimately used for parameter validation, rather than solely as a form of inline self-test.

Rather than changing the assert statement, an alternative option would be to provide a new builtin (suggested name: "ensure") that raises ValidationError (a new subclass of AssertionError) if the first argument is false.

As a function, the new builtin could accept parameters for:

• the message to be reported on failure
• the exception type to be raised on failure

And since it would only be a new builtin rather than a new keyword, existing uses of the name "ensure" would be unaffected (except to the extent that linters may start warning about shadowing a builtin).

(Since it's a suggestion for a new builtin, actually doing this would require a PEP, which I'm not planning to write, I just wanted to get the suggestion explicitly on the record rather than leaving it buried in mailing list archives)

[stevendaprano]

Oh I can just imagine the bike-shedding on this one :-)

I'm not really convinced this is needed, but for what it's worth I think that given the intended use-case (checking function parameters) ValueError would be a more appropriate default exception type. The given argument has the wrong value, hence ValueError.

On the other hand, it is more common (at least for me) to check arguments with isinstance, so maybe the default should be TypeError.

Definitely needs a PEP.

[stevendaprano]

Since this is intended for argument checking, i.e. testing preconditions, the Eiffel term "require" seems more appropriate.

https://www.eiffel.org/doc/eiffel/ET:%20Design%20by%20Contract%20(tm),%20Assertions%20and%20Exceptions#Preconditions

[bitdancer]

I'm not clear why we want a bug tracker issue for something that is still only an idea. We generally *send* people to python-ideas when they propose half-baked ideas here :) (Not actually saying your idea is half-baked, but it clearly isn't fully baked since there's no PEP.)

There is literally no point in discussing this proposal here. Normally for an issue like this (where we've redirected someone to python-ideas for discussion) we would close the issue and tell them to come back and re-open it if there is a positive consensus on python-ideas. Since you are designating this as PEP level, there seems to be no reason to keep the issue open.

[brettcannon]

I agree w/ David that this idea is premature. Plus I say it's easier to make it so -O is more fine-grained so you can leave in asserts but get __debug__ set to False.

[smarie]

Very much interested by the topic.

For reference I tried to summarize the status of inline type and value validation here: https://smarie.github.io/python-valid8/why_validation/

And I proposed a solution with a library here https://smarie.github.io/python-valid8 (with a somewhat smart handling of the ValueError / TypeError inheritance dilemma, for what's worth)

[ncoghlan]

I agreed that this idea isn't really baked enough for an RFE yet, so I'm marking this as "postponed" for now.

The main requirement for getting it back out of "postponed" state would be having someone that's sufficiently interested to write a PEP and wrangle some related python-ideas threads.