Why doesn't Python (error msg) tell me WHAT the actual (arg) values are ?

[Thomas Passin]

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.
>