This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: A better assert statement
Type: enhancement Stage:
Components: Versions: Python 3.10
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: ammar2, barry, iritkatriel, rhettinger, serhiy.storchaka
Priority: normal Keywords:

Created on 2016-04-06 14:43 by barry, last changed 2022-04-11 14:58 by admin.

Messages (6)
msg262946 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2016-04-06 14:43
Too many times I hit failing assert statements, and have no idea what value is causing the assertion to fail.  Sure, you can provide a value to print (instead of just the failing code) but it seems to be fairly rarely used.  And it can also lead to code duplication.  As an example, I saw this today in some installed code:

assert k.replace('.', '').replace('-', '').replace('_', '').isalum()

So now I have to sudo edit the installed system file, duplicate everything up to but not including the .isalum() as the second argument to assert, then try to reproduce the problem.  IWBNI assert could make this better.

One idea would be to split the value and the conditional being asserted on that value, but we can't use two-argument asserts for that.  Crazy syntax thought: reuse the 'with' keyword:

assert k.replace('.', '').replace('-', '').replace('_', '') with isalum

where the part before the 'with' is 'value' and the part after the 'with' is conditional, and the two parts together imply the expression.

This would be equivalent to:

if __debug__:
    if not value.conditional():
        raise AssertionError(expression, value, conditional)

I suppose you then want to support arguments:

assert foo with can_bar, 1, 2, x=3

but maybe that's YAGNI and we can just say to use a better 2-value assert in those more complicated cases.
msg262948 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-04-06 15:07
I think in this particular case you are more interesting in the value of k than k.replace('.', '').replace('-', '').replace('_', '').
msg262949 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2016-04-06 15:11
On Apr 06, 2016, at 03:07 PM, Serhiy Storchaka wrote:

>I think in this particular case you are more interesting in the value of k
>than k.replace('.', '').replace('-', '').replace('_', '').

Possibly so.
msg264940 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-05-06 06:45
I'm -1 for changing syntax of assert.

But I think that it may be useful to change semantic of assert so that all intermediate results of subexpressions are saved and included in the assert report (or at least their shortened reprs). I'm +0 for this.
msg389653 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2021-03-28 22:47
Maybe we could use the walrus operator for this: make assert display the reprs of all named sub-expressions.
msg389655 - (view) Author: Ammar Askar (ammar2) * (Python committer) Date: 2021-03-29 03:22
Just a note and possible design inspiration, pytest has pretty assertions like this to allowing you to write unit tests purely with the assert statement and not unittest's special `assert...` methods: https://docs.pytest.org/en/stable/example/reportingdemo.html#tbreportdemo
History
Date User Action Args
2022-04-11 14:58:29adminsetgithub: 70889
2021-03-29 03:22:25ammar2setnosy: + ammar2
messages: + msg389655
2021-03-28 22:47:18iritkatrielsetversions: + Python 3.10, - Python 3.6
nosy: + iritkatriel

messages: + msg389653

type: enhancement
2016-05-06 06:45:17serhiy.storchakasetmessages: + msg264940
2016-04-06 15:11:25barrysetmessages: + msg262949
2016-04-06 15:07:12serhiy.storchakasetnosy: + rhettinger, serhiy.storchaka
messages: + msg262948
2016-04-06 14:43:37barrycreate