Skip to content

Show repr for callables used in an assert directly #11525

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
The-Compiler opened this issue Oct 20, 2023 · 4 comments · Fixed by #12473
Closed

Show repr for callables used in an assert directly #11525

The-Compiler opened this issue Oct 20, 2023 · 4 comments · Fixed by #12473
Labels
topic: reporting related to terminal output and user-facing messages and errors

Comments

@The-Compiler
Copy link
Member

With something like

import pytest

@pytest.fixture
def fixt():
    return 42

def test_something():  # missing "fixt" argument
    print(fixt)
    assert fixt == 42

(which is a common beginners mistake), pytest prints:

======================================= test session starts ========================================
collected 1 item

tmp31nzhe4b.py F                                                                             [100%]

============================================= FAILURES =============================================
__________________________________________ test_something __________________________________________

    def test_something():  # missing "fixt" argument
        print(fixt)
>       assert fixt == 42
E       assert fixt == 42

/tmp/ipykernel_77860/2395276065.py:9: AssertionError
--------------------------------------- Captured stdout call ---------------------------------------
<function fixt at 0x7fd7745c4160>
===================================== short test summary info ======================================
FAILED tmp31nzhe4b.py::test_something - assert fixt == 42
======================================== 1 failed in 0.03s =========================================

notably, without anything making it clear that fixt is a function, and not the value the user actually expected. Only when we print(fixt) it becomes clear that this is a function object and what the mistake was.

This is due to:

def _should_repr_global_name(obj: object) -> bool:
if callable(obj):
return False

which was originally introduced in 65edf87.

The rationale for it can be found in the related issue:

and it boils down to:

I think in some cases it can result in too verbose output, especially when using builtins where you don't really want to have extra information on "len", "callable" etc.

and

Another reason for this heuristic occurred to me: Many commonly used global names like classes and modules are more nicely displayed by their name rather than their repr.

I believe this is useful in cases like assert len(values) == 2 where we really don't need to drill down into what len is. However, it hides vital information in the case that one side of the == is a global callable directly, rather than it being used as a part of a bigger expression.

@RonnyPfannschmidt
Copy link
Member

As fixtures are no longer callable, how about turning them into actual objects

@Zac-HD Zac-HD added the topic: reporting related to terminal output and user-facing messages and errors label Oct 21, 2023
@Zac-HD
Copy link
Member

Zac-HD commented Oct 21, 2023

I think changing the if callable(obj): return False may make sense; but I support changing the repr of fixtures to make it obvious that they are fixtures regardless of that.

@The-Compiler
Copy link
Member Author

As fixtures are no longer callable, how about turning them into actual objects

Depends on what you mean by "actual objects". As long as they are still defined as functions, I'd be somewhat conservative about doing too much stuff with them. I don't know, but decorating a function turning that into something completely different from a function sounds kinda weird to me. Then again, maybe it's fine...

@RonnyPfannschmidt
Copy link
Member

Having fixtures as Definition objects that aren't callable instead of functions that fail might be a blessing when just wanting to search them

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: reporting related to terminal output and user-facing messages and errors
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants