Why doesn't Python (error msg) tell me WHAT the actual (arg) values are ?
Thomas Passin
list1 at tompassin.net
Fri Feb 24 18:19:52 EST 2023
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.
>
More information about the Python-list
mailing list