|
|
@ -148,7 +148,7 @@ This could be especially useful during testing, as it's very easy to override a |
|
|
|
|
|
|
|
|
Coming from the previous example, your `config.py` file could look like: |
|
|
Coming from the previous example, your `config.py` file could look like: |
|
|
|
|
|
|
|
|
{* ../../docs_src/settings/app02/config.py hl[10] *} |
|
|
{* ../../docs_src/settings/app02_an_py39/config.py hl[10] *} |
|
|
|
|
|
|
|
|
Notice that now we don't create a default instance `settings = Settings()`. |
|
|
Notice that now we don't create a default instance `settings = Settings()`. |
|
|
|
|
|
|
|
|
@ -174,7 +174,7 @@ And then we can require it from the *path operation function* as a dependency an |
|
|
|
|
|
|
|
|
Then it would be very easy to provide a different settings object during testing by creating a dependency override for `get_settings`: |
|
|
Then it would be very easy to provide a different settings object during testing by creating a dependency override for `get_settings`: |
|
|
|
|
|
|
|
|
{* ../../docs_src/settings/app02/test_main.py hl[9:10,13,21] *} |
|
|
{* ../../docs_src/settings/app02_an_py39/test_main.py hl[9:10,13,21] *} |
|
|
|
|
|
|
|
|
In the dependency override we set a new value for the `admin_email` when creating the new `Settings` object, and then we return that new object. |
|
|
In the dependency override we set a new value for the `admin_email` when creating the new `Settings` object, and then we return that new object. |
|
|
|
|
|
|
|
|
|