Imports are grouped into paragraphs, and these paragraphs are in a
particular order: first are the “from future” import and six. Second
are imports of the standard library (possibly via six). This is
followed by imports of third party packages and finally a paragraph
with imports of our own modules.

We do not believe that generic slogans and rules can absolutely
dictate design: real understanding of an actual situation and
necessary trade-offs is needed. That said, we’re ‘fond of’ the
following values:

Often, you need access to something from many places in code. Examples
of this is: the configuration of the system, the current database
transaction or the current web request.

Our solution is to accept that code executes within a current
ExecutionContext which contains some important global-ish elements.

The ExecutionContext is not supposed to be extended. It contains a few
very specific things that get set up by the framework:

The configuration of the system;

Ways to manage databases, persistence and database transactions;

The current user session; and

The current web request.

The idea of such a global context is criticised because it can make
testing difficult: you may want to test code that is dependent on such
a magic context. We mitigate this problem in the following way:

context is stack-based

ContextAwareFixture ensures all tests always have a context and that setup/teardown/singleton methods happen inside the right context

We have a Context within which all tests and the participating web server runs

We have a Context (a copy) within which each test runs, but which does not carry over side-effects

If you understand above mentioned context stuff, you can pretty much live in testing world without much bother.