Update coverage to 4.3.4

[pyup-bot]

There's a new version of coverage available.
You are currently using 4.3.1. I have updated it to 4.3.4

These links might come in handy: PyPI | Changelog | Docs

Changelog

4.3.4

---

• Fixing 2.6 in version 4.3.3 broke other things, because the too-tricky
  exception wasn't properly derived from Exception, described in issue 556_.
  A newb mistake; it hasn't been a good few days.

.. _issue 556: https://bitbucket.org/ned/coveragepy/issues/556/43-fails-if-there-are-html-files-in-the

.. _changes_433:

4.3.3

---

• Python 2.6 support was broken due to a testing exception imported for the
  benefit of the coverage.py test suite. Properly conditionalizing it fixed
  issue 554_ so that Python 2.6 works again.

.. _issue 554: https://bitbucket.org/ned/coveragepy/issues/554/traceback-on-python-26-starting-with-432

.. _changes_432:

4.3.2

---

• Using the --skip-covered option on an HTML report with 100% coverage
  would cause a "No data to report" error, as reported in issue 549_. This is
  now fixed; thanks, Loïc Dachary.

• If-statements can be optimized away during compilation, for example, if 0:
  or if __debug__:. Coverage.py had problems properly understanding these
  statements which existed in the source, but not in the compiled bytecode.
  This problem, reported in issue 522_, is now fixed.

• If you specified --source as a directory, then coverage.py would look for
  importable Python files in that directory, and could identify ones that had
  never been executed at all. But if you specified it as a package name, that
  detection wasn't performed. Now it is, closing issue 426_. Thanks to Loïc
  Dachary for the fix.

• If you started and stopped coverage measurement thousands of times in your
  process, you could crash Python with a "Fatal Python error: deallocating
  None" error. This is now fixed. Thanks to Alex Groce for the bug report.

• On PyPy, measuring coverage in subprocesses could produce a warning: "Trace
  function changed, measurement is likely wrong: None". This was spurious, and
  has been suppressed.

• Previously, coverage.py couldn't start on Jython, due to that implementation
  missing the multiprocessing module (issue 551). This problem has now been
  fixed. Also, issue 322 about not being able to invoke coverage
  conveniently, seems much better: jython -m coverage run myprog.py works
  properly.

• Let's say you ran the HTML report over and over again in the same output
  directory, with --skip-covered. And imagine due to your heroic
  test-writing efforts, a file just acheived the goal of 100% coverage. With
  coverage.py 4.3, the old HTML file with the less-than-100% coverage would be
  left behind. This file is now properly deleted.

.. _issue 322: https://bitbucket.org/ned/coveragepy/issues/322/cannot-use-coverage-with-jython
.. issue 426: https://bitbucket.org/ned/coveragepy/issues/426/difference-between-coverage-results-with
.. issue 522: https://bitbucket.org/ned/coveragepy/issues/522/incorrect-branch-reporting-with-__debug
.. _issue 549: https://bitbucket.org/ned/coveragepy/issues/549/skip-covered-with-100-coverage-throws-a-no
.. _issue 551: https://bitbucket.org/ned/coveragepy/issues/551/coveragepy-cannot-be-imported-in-jython27

.. _changes_431:

Got merge conflicts? Close this PR and delete the branch. I'll create a new PR for you.

Happy merging! 🤖

[coveralls]

Coverage remained the same at 99.526% when pulling 1482916 on pyup-update-coverage-4.3.1-to-4.3.4 into 5225682 on master.

[coveralls]

Coverage remained the same at 99.526% when pulling d16be30 on pyup-update-coverage-4.3.1-to-4.3.4 into 82edde8 on master.

[delgadom]

lgtm

[coveralls]

Coverage remained the same at 99.526% when pulling 268b6c4 on pyup-update-coverage-4.3.1-to-4.3.4 into f0d6258 on master.