python unit tests structure - how to better structure project with multiple packages and many tests files?

From a general (language independent) perspective I see two main criteria when it comes to the question where in the package structure to put the test files:

1. Maintaining a clear barrier between production code and test code: Production code should be separated from test code. For some kinds of software this is not just a recommendation, but a strict requirement (for example in safety critical software) - even if the test code within the production code would be dead code or unreachable. But, a clear barrier can also be advantageous when designing tests: separation helps to first focus on tests on the public API. And, sometimes you want to deliver production code to the customer but not the unit-test code or vice-versa (depending on the contract). This is, obviously, the simpler to achieve the more production code and test code are separated.

2. Mutual traceability between production code and related test code: Traceability is easy to achieve when production code and test code are versioned together. Typical commits to the repository could then contain production code changes and related changes to the tests. Putting production code and tests into different projects would be a disadvantage here - unless you can somehow ensure that both related projects are consistently versioned, such that it is always clear which versions belong together. If you would have to ensure this manually, it is likely to fail.

The solution you have shown clearly supports criterion #1, but the separation of the tests from their respective packages makes it more difficut to fulfill criterion #2. For Python, I find the option to put the tests into a subpackage more appealing. See for example https://python-packaging.readthedocs.io/en/latest/testing.html:

project/
    package_1/
        __init__.py
        package_1_class_1.py
        package_1_class_2.py
        package_1_class_3.py
        tests/
            __init__.py
            test_package_1_class_1.py
            test_package_1_class_2.py
            test_package_1_class_3.py
    package_2/
        package_2_class_1.py
        package_2_class_2.py
        package_2_class_3.py
        package_2_class_4.py
        tests/
            __init__.py
            test_package_2_class_1.py
            test_package_2_class_2.py
            test_package_2_class_3.py
            test_package_2_class_4.py
    package_3/
        __init__.py
        package_3_class_1.py
        package_3_class_2.py
        tests/
            __init__.py
            test_package_3_class_1.py
            test_package_3_class_2.py
    setup.py
    ...

For example, this allows you to easily later re-use the individual packages including their tests in different projects: Everything belonging to a package is in the same directory structure.