Thanks, and apologies for the long delay!

use setuptools and add a declarative config for setup.py

Could you explain the advantages (and possible disadvantages) of this?

Could you roll back the unbundling of six.py? I prefer to avoid the external dependency.

Could you explain the advantages (and possible disadvantages) of this?

More declarative config, no code at all. And all projects settings are in one place.

Not sure about disadvantages, maybe version requirements for the setuptools, that disallow ancient stuff. I can lower this down to 30.3.0. The price is some repetition for *requires options: we can't reference extras requirements like

tests_require = mpmath[tests]

Could you roll back the unbundling of six.py? I prefer to avoid the external dependency.

Can you explain some technical reasons behind of this? pip can handle external dependencies well, by design. In turn, you already have very outdated six.py file, almost uncovered by tests. An option may be copy&paste only very tiny part of the six, which is actually used and will be well maintained.

It looks like we only depend on exec_ and print_ from six.py. I suppose we could just move those to backend.py? We don't even need the full print_, really; it's just used in a handful of places for concatenating strings.

No dependency = one less thing that can go wrong.

Ok, dependency on six was removed. Note bad coverage on this new diff - implemented exec_() on PY2 wasn't covered at all. Should we run coverage tests on PY2 just for this tiny function? (That is an example, why dependencies are good for business - other people will test their stuff.)

(BTW, codecov.yml taken from the diofant, you may want less strict patch requirements.)

Ok, dependency on six was removed. Note bad coverage on this new diff - implemented exec_() on PY2 wasn't covered at all.

That must be because PY2 isn't covered at all. exec_ is heavily used, to implement the binary operations for the mpf type and for hypergeometric series!

That must be because PY2 isn't covered at all.

Of course. The question was: should we enable coverage testing on PY2 just for that single function?

I don't understand the problem.

I don't understand the problem.

For example, travis build will take longer time (COVERAGE=on jobs more then 2x times slower then usual).

Ok, now code coverage collected for 2.7 too. Please restart failed job.

Good! And now the fun game of raising the coverage% begins :)

Does coverage testing ignore doctests?

No. pytest is collecting doctests per default (i.e. we run it with --doctest-modules):

$ py.test mpmath/calculus/optimization.py
============================= test session starts ==============================
platform linux -- Python 3.7.1, pytest-4.2.0, py-1.7.0, pluggy-0.8.1
hypothesis profile 'default' -> database=DirectoryBasedExampleDatabase('/home/sk/src/mpmath/.hypothesis/examples')
rootdir: /home/sk/src/mpmath, inifile: setup.cfg
plugins: xdist-1.26.1, timeout-1.3.3, forked-1.0.1, cov-2.6.1, hypothesis-4.4.3
collected 3 items                                                              

mpmath/calculus/optimization.py ...                                      [100%]

=========================== 3 passed in 0.37 seconds ===========================

But there may be problems, which I miss, may be with dynamic docstrings or something.

Example: libmp.libintmath.stirling1 is reported as not covered, but should be covered via the doctest for mpmath.stirling1.

Another example: functions.qfunctions.qhyper is reported as not covered, but has its own doctests.

libmp.libintmath.stirling1 is reported as not covered, but should be covered via the doctest for mpmath.stirling1.
Another..

I see. These seems to be the mentioned above cases with dynamic __doc__.

That's bizarre -- the docstrings in functions/qfunctions.py are not dynamic.

In either case, if the test runner doesn't run all doctests, that's not good.

the docstrings in functions/qfunctions.py are not dynamic

Hmm, indeed. This case seems to be related with broken defun* decorators, see #432.