On 2/24/2023 2:47 PM, dn via Python-list wrote:
On 25/02/2023 08.12, Peter J. Holzer wrote:
On 2023-02-24 16:12:10 +1300, dn via Python-list wrote:
In some ways, providing this information seems appropriate.
Curiously, this
does not even occur during an assert exception - despite the
value/relationship being the whole point of using the command!
x = 1
assert x == 2
AssertionError (and that's it)
Sometimes you can use a second parameter to assert if you know what kind
of error to expect:
>>> a = [1,2,3]
>>> b = [4,5]
>>> assert len(a) == len(b), f'len(a): {len(a)} != len(b): {len(b)}'
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AssertionError: len(a): 3 != len(b): 2
With type errors, assert may actually give you the information needed:
>>> c = {"a": a, "b": 2}
>>> assert a > c
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: '>' not supported between instances of 'list' and 'dict'
So now we know that a is a list and c is a dictionary.
Pytest is great there. If an assertion in a test case fails it analyzes
the expression to give you various levels of details:
======================================== test session starts
========================================
platform linux -- Python 3.10.6, pytest-6.2.5, py-1.10.0, pluggy-0.13.0
rootdir: /home/hjp/tmp/t
plugins: cov-3.0.0, anyio-3.6.1
collected 1 item
test_a.py
F [100%]
============================================= FAILURES
==============================================
______________________________________________ test_a
_______________________________________________
def test_a():
a = [1, 2, 3]
b = {"a": a, "b": 2}
assert len(a) == len(b)
E AssertionError: assert 3 == 2
E + where 3 = len([1, 2, 3])
E + and 2 = len({'a': [1, 2, 3], 'b': 2})
test_a.py:7: AssertionError
====================================== short test summary info
======================================
FAILED test_a.py::test_a - AssertionError: assert 3 == 2
========================================= 1 failed in 0.09s
=========================================
+1
and hence the tone of slight surprise in the observation - because only
ever use assert within pytests, and as observed, pytest amplifies the
report-back to provide actionable-intelligence. See also: earlier
contribution about using a debugger.
That said, have observed coders 'graduating' from other languages,
making wider use of assert - assumed to be more data (value)
sanity-checks than typing, but ...
Do you use assert frequently?
The OP seems wedded to his?her ways, complaining that Python does not
work the way it 'should'. In turn, gives rise to the impression that
expounding the advantages of TDD, and thus anticipating such unit and
integration error-possibilities, might be considered an insult or
unhelpful.
(sigh!)
Personally, I struggled a bit to adapt from the more-strictured (if not
more-structured) languages of my past, to Python - particularly the
different philosophies or emphases of what happens at 'compile-time' cf
'execution-time'; and how such required marked changes in attitudes to
design, time-allocation, work-flow, and tool-set. Two related-activities
which made the language-change more workable and unleashed greater than
step-change advantage, were: increased use of TDD, and actively learning
the facilities within Python-oriented IDEs.
--
https://mail.python.org/mailman/listinfo/python-list
