Skip to content

Conversation

@jaraco
Copy link
Contributor

@jaraco jaraco commented Feb 13, 2018

... to avoid losing reference to stdout. Fixes #985.

This patch implements the change proposed, but encapsulates the workaround and documents it with a docstring.

  • Create a new changelog file in the changelog folder, with a name like <ISSUE NUMBER>.<TYPE>.rst. See changelog/README.rst for details.
  • Target the master branch for bug fixes, documentation updates and trivial changes.
  • Target the features branch for new features and removals/deprecations.
  • Include documentation when adding new features.
  • Include new tests or update existing tests when applicable.

@jaraco
Copy link
Contributor Author

jaraco commented Feb 13, 2018

By applying the fix, the test now passes (on macOS Python 3.6) and the behavior is also corrected in real-world testing. I didn't see any concerns about applying this patch. Are there any?

@coveralls
Copy link

coveralls commented Feb 13, 2018

Coverage Status

Coverage decreased (-0.1%) to 92.498% when pulling 4131d3f on bugfix/985/disable-output-capturing-in-doctest into e7bcc85 on master.

@jaraco
Copy link
Contributor Author

jaraco commented Feb 13, 2018

I don't understand why the test is still failing on Linux. I thought the test was previously only failing on macOS. How is it adding the fix improves the behavior for macOS but breaks the behavior for Linux? I'm tempted to constrain the fix to macOS only (acknowledging it's a hack) until such a time that a robust solution can be devised.

self._disable_output_capturing()
self.runner.run(self.dtest)

def _disable_output_capturing(self):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please include the platform name in the method name since its a platform hack
i propose _disable_output_capturing_for_darwin

Copy link
Member

@RonnyPfannschmidt RonnyPfannschmidt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well done, thanks 👍

if capman:
out, err = capman.suspend_global_capture(in_=True)
sys.stdout.write(out)
sys.stdout.write(err)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

err might be undefinded here if bool(capman) is False.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm. I'd consider that contingency unlikely (negligible) unless capture managers are expected to present as __bool__() == False under some condition.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if the capturemanager is disabled by a cli option the code would fail
please lets use consisted indentation for the related code

for overly pedantic correctness it might make sense to change the check to is None

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, no harm being consistent. Btw, shouldn't the last line write to sys.stderr instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if the capturemanager is disabled by a cli option the code would fail

I'm afraid I'm not following. Do you mean --capture=no? As I understand it, passing that parameter would mean that bool(capman) == True. And I tested it, and it works fine.

I think I see what you're saying - that on line 121, err won't have been defined if the capman was False. And that would happen by disabling the plugin entirely, such as with -p no:capturemanager. Testing that, I get this output. It's not quite what I expected. The code didn't fail anywhere near doctest.py.

please lets use consisted indentation for the related code

At first, I thought this was a stylistic comment, but I see now that you've recognized an error I introduced when I copied this code from the original.

for overly pedantic correctness it might make sense to change the check to is None

I'm not sure about that. It may be the case that if the capture manager defines __bool__ which returns False, that's also a condition that should be bypassed (correctly). Since it doesn't define it either way, the boolean test currently seems to me to be correct either way, at which point I prefer the shorter code.

Btw, shouldn't the last line write to sys.stderr instead?

Yes, that does seem incongruent. I'll test with this suggestion.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I was eventually able to trigger the UnboundLocalError. I had to disable the capture manager and make sure to pass --doctest-modules to the test run as well (forgot about that before).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

err might be undefinded here if bool(capman) is False.

Now that I re-read the original comment, I see that was the sole concern, and I was on an unrelated tangent.

@jaraco
Copy link
Contributor Author

jaraco commented Feb 17, 2018

I honestly still don't understand why it's necessary to write out captured streams when suspending the capture. I also don't understand why adding this new suspension routine doesn't require a symmetric operation (to unsuspend). But honestly, it seems to work, and until someone can show a use-case that this breaks, I'd like to move forward with it, as the status-quo is pdb is often broken in the test suites where I use doctests (which is almost all of them).

Copy link
Member

@nicoddemus nicoddemus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jaraco!

@nicoddemus nicoddemus merged commit 9d879be into master Feb 17, 2018
@nicoddemus nicoddemus deleted the bugfix/985/disable-output-capturing-in-doctest branch February 17, 2018 20:39
@twmr twmr changed the title Disable output capturing in doctest Disable output capturing in doctest on macOS Feb 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

pdb prompt unusable if doctests ran first (macOS and Python 3)

6 participants