This is probably a good point to add that I do try to generally avoid globals as well. I am a fan of limiting mutable state in general. But for constants (whether they are hard coded in the source code or read from a file doesn’t really matter to me) they make sense.
And just to emphasize again, if you are building an App with user settings that may be changed during runtime, the „global constant config“ pattern does not apply. It only really works for static configuration read at startup.
For a mutable runtime config, you really have to think hard about when it is allowed to change and how these changes are propagated throughout your app, otherwise you may end up with inconsistent behavior where part of your program still uses the old values. There’s many ways to solve this depending on the programs architecture and requirements though.
In Rust, the tests usually sit right next to the source code, even in the same file. That’s partly because the compiler can just strip the tests from the final binary, and I assume partly just conventional. In Python, you usually want to keep the tests out of the final sdist/wheel, so the setup you described is probably the most common in bigger projects.