Skip to content
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

[Suggestion] Use a namedtuple for capsys results #2879

Closed
samueldg opened this issue Oct 27, 2017 · 5 comments
Closed

[Suggestion] Use a namedtuple for capsys results #2879

samueldg opened this issue Oct 27, 2017 · 5 comments
Labels
good first issue easy issue that is friendly to new contributor type: enhancement new feature or API change, should be merged into features branch

Comments

@samueldg
Copy link
Contributor

Currently, the capsys fixture's readouterr() method returns a tuple with (stdout, stderr) results.

Usage will look something like this:

def test_print_1(capsys):
    print('something')
    out, err = capsys.readouterr()  # Named, unused variable
    assert 'something' in out

def test_print_2(capsys):
    print('something ')
    out, _ = capsys.readouterr()  # Anonymous, ignored variable
    assert 'something' in out

def test_print_3(capsys):
    print('something')
    assert 'something' in capsys.readouterr()[0]  # Index access (not super readable)

My suggestion would be to return a namedtuple instead, so the attributes can be accessed by name

def test_print_4(capsys):
    print('something')
    assert 'something' in capsys.readouterr().out  # Attribute access

Which could be achieved by wrapping the result with something like:

from collections import namedtuple
CapsysResult = namedtuple('CapsysResult', ['out', 'err'])

This would be pretty straightforward, and still fully compatible with existing code using tuples either for index access or unpacking.

@samueldg
Copy link
Contributor Author

Let me know if that's something you'd want in, I'd gladly submit a PR.

@nicoddemus nicoddemus added good first issue easy issue that is friendly to new contributor type: enhancement new feature or API change, should be merged into features branch labels Oct 27, 2017
@nicoddemus
Copy link
Member

@samueldg that's a perfect case where changing to a namedtuple is a great idea. A PR would be greatly appreciated, thanks! (Make sure to target the features branch)

samueldg added a commit to samueldg/pytest that referenced this issue Oct 28, 2017
@samueldg
Copy link
Contributor Author

@nicoddemus There you go: #2880

@nicoddemus
Copy link
Member

Awesome, thanks!

@RonnyPfannschmidt
Copy link
Member

closed by #2880

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue easy issue that is friendly to new contributor type: enhancement new feature or API change, should be merged into features branch
Projects
None yet
Development

No branches or pull requests

3 participants