✏️ Fix typo: convert every 're-use' to 'reuse'. (#11598)

docs/en/docs/advanced/additional-responses.md

@@ -224,7 +224,7 @@ Here, `new_dict` will contain all the key-value pairs from `old_dict` plus the n
 }
 ```
 
-You can use that technique to re-use some predefined responses in your *path operations* and combine them with additional custom ones.
+You can use that technique to reuse some predefined responses in your *path operations* and combine them with additional custom ones.
 
 For example:
 

docs/en/docs/advanced/path-operation-advanced-configuration.md

@@ -187,6 +187,6 @@ And then in our code, we parse that YAML content directly, and then we are again
     In Pydantic version 1 the method to parse and validate an object was `Item.parse_obj()`, in Pydantic version 2, the method is called `Item.model_validate()`.
 
 !!! tip
-    Here we re-use the same Pydantic model.
+    Here we reuse the same Pydantic model.
 
     But the same way, we could have validated it in some other way.

docs/en/docs/advanced/security/oauth2-scopes.md

@@ -361,7 +361,7 @@ It will have a property `scopes` with a list containing all the scopes required
 
 The `security_scopes` object (of class `SecurityScopes`) also provides a `scope_str` attribute with a single string, containing those scopes separated by spaces (we are going to use it).
 
-We create an `HTTPException` that we can re-use (`raise`) later at several points.
+We create an `HTTPException` that we can reuse (`raise`) later at several points.
 
 In this exception, we include the scopes required (if any) as a string separated by spaces (using `scope_str`). We put that string containing the scopes in the `WWW-Authenticate` header (this is part of the spec).
 

docs/en/docs/advanced/settings.md

@@ -369,7 +369,7 @@ Here we define the config `env_file` inside of your Pydantic `Settings` class, a
 
 ### Creating the `Settings` only once with `lru_cache`
 
-Reading a file from disk is normally a costly (slow) operation, so you probably want to do it only once and then re-use the same settings object, instead of reading it for each request.
+Reading a file from disk is normally a costly (slow) operation, so you probably want to do it only once and then reuse the same settings object, instead of reading it for each request.
 
 But every time we do:
 

docs/en/docs/advanced/templates.md

@@ -23,7 +23,7 @@ $ pip install jinja2
 ## Using `Jinja2Templates`
 
 * Import `Jinja2Templates`.
-* Create a `templates` object that you can re-use later.
+* Create a `templates` object that you can reuse later.
 * Declare a `Request` parameter in the *path operation* that will return a template.
 * Use the `templates` you created to render and return a `TemplateResponse`, pass the name of the template, the request object, and a "context" dictionary with key-value pairs to be used inside of the Jinja2 template.
 

docs/en/docs/deployment/docker.md

@@ -70,7 +70,7 @@ And there are many other images for different things like databases, for example
 
 By using a pre-made container image it's very easy to **combine** and use different tools. For example, to try out a new database. In most cases, you can use the **official images**, and just configure them with environment variables.
 
-That way, in many cases you can learn about containers and Docker and re-use that knowledge with many different tools and components.
+That way, in many cases you can learn about containers and Docker and reuse that knowledge with many different tools and components.
 
 So, you would run **multiple containers** with different things, like a database, a Python application, a web server with a React frontend application, and connect them together via their internal network.
 
@@ -249,7 +249,7 @@ COPY ./requirements.txt /code/requirements.txt
 
 Docker and other tools **build** these container images **incrementally**, adding **one layer on top of the other**, starting from the top of the `Dockerfile` and adding any files created by each of the instructions of the `Dockerfile`.
 
-Docker and similar tools also use an **internal cache** when building the image, if a file hasn't changed since the last time building the container image, then it will **re-use the same layer** created the last time, instead of copying the file again and creating a new layer from scratch.
+Docker and similar tools also use an **internal cache** when building the image, if a file hasn't changed since the last time building the container image, then it will **reuse the same layer** created the last time, instead of copying the file again and creating a new layer from scratch.
 
 Just avoiding the copy of files doesn't necessarily improve things too much, but because it used the cache for that step, it can **use the cache for the next step**. For example, it could use the cache for the instruction that installs dependencies with:
 

docs/en/docs/how-to/custom-docs-ui-assets.md

@@ -26,7 +26,7 @@ To disable them, set their URLs to `None` when creating your `FastAPI` app:
 
 Now you can create the *path operations* for the custom docs.
 
-You can re-use FastAPI's internal functions to create the HTML pages for the docs, and pass them the needed arguments:
+You can reuse FastAPI's internal functions to create the HTML pages for the docs, and pass them the needed arguments:
 
 * `openapi_url`: the URL where the HTML page for the docs can get the OpenAPI schema for your API. You can use here the attribute `app.openapi_url`.
 * `title`: the title of your API.
@@ -163,7 +163,7 @@ To disable them, set their URLs to `None` when creating your `FastAPI` app:
 
 And the same way as with a custom CDN, now you can create the *path operations* for the custom docs.
 
-Again, you can re-use FastAPI's internal functions to create the HTML pages for the docs, and pass them the needed arguments:
+Again, you can reuse FastAPI's internal functions to create the HTML pages for the docs, and pass them the needed arguments:
 
 * `openapi_url`: the URL where the HTML page for the docs can get the OpenAPI schema for your API. You can use here the attribute `app.openapi_url`.
 * `title`: the title of your API.

docs/en/docs/how-to/nosql-databases-couchbase.md

@@ -108,7 +108,7 @@ Now create a function that will:
 * Get the document with that ID.
 * Put the contents of the document in a `UserInDB` model.
 
-By creating a function that is only dedicated to getting your user from a `username` (or any other parameter) independent of your *path operation function*, you can more easily re-use it in multiple parts and also add <abbr title="Automated test, written in code, that checks if another piece of code is working correctly.">unit tests</abbr> for it:
+By creating a function that is only dedicated to getting your user from a `username` (or any other parameter) independent of your *path operation function*, you can more easily reuse it in multiple parts and also add <abbr title="Automated test, written in code, that checks if another piece of code is working correctly.">unit tests</abbr> for it:
 
 ```Python hl_lines="36-42"
 {!../../../docs_src/nosql_databases/tutorial001.py!}

docs/en/docs/release-notes.md

@@ -3872,7 +3872,7 @@ Note: all the previous parameters are still there, so it's still possible to dec
     * New documentation about exceptions handlers:
         * [Install custom exception handlers](https://fastapi.tiangolo.com/tutorial/handling-errors/#install-custom-exception-handlers).
         * [Override the default exception handlers](https://fastapi.tiangolo.com/tutorial/handling-errors/#override-the-default-exception-handlers).
-        * [Re-use **FastAPI's** exception handlers](https://fastapi.tiangolo.com/tutorial/handling-errors/#re-use-fastapis-exception-handlers).
+        * [Reuse **FastAPI's** exception handlers](https://fastapi.tiangolo.com/tutorial/handling-errors/#reuse-fastapis-exception-handlers).
     * PR [#273](https://github.com/tiangolo/fastapi/pull/273).
 
 * Fix support for *paths* in *path parameters* without needing explicit `Path(...)`.

docs/en/docs/tutorial/background-tasks.md

@@ -55,7 +55,7 @@ Inside of your *path operation function*, pass your task function to the *backgr
 
 Using `BackgroundTasks` also works with the dependency injection system, you can declare a parameter of type `BackgroundTasks` at multiple levels: in a *path operation function*, in a dependency (dependable), in a sub-dependency, etc.
 
-**FastAPI** knows what to do in each case and how to re-use the same object, so that all the background tasks are merged together and are run in the background afterwards:
+**FastAPI** knows what to do in each case and how to reuse the same object, so that all the background tasks are merged together and are run in the background afterwards:
 
 === "Python 3.10+"
 

docs/en/docs/tutorial/dependencies/dependencies-in-path-operation-decorators.md

@@ -107,7 +107,7 @@ These dependencies can `raise` exceptions, the same as normal dependencies:
 
 And they can return values or not, the values won't be used.
 
-So, you can re-use a normal dependency (that returns a value) you already use somewhere else, and even though the value won't be used, the dependency will be executed:
+So, you can reuse a normal dependency (that returns a value) you already use somewhere else, and even though the value won't be used, the dependency will be executed:
 
 === "Python 3.9+"
 

docs/en/docs/tutorial/dependencies/sub-dependencies.md

@@ -157,7 +157,7 @@ query_extractor --> query_or_cookie_extractor --> read_query
 
 If one of your dependencies is declared multiple times for the same *path operation*, for example, multiple dependencies have a common sub-dependency, **FastAPI** will know to call that sub-dependency only once per request.
 
-And it will save the returned value in a <abbr title="A utility/system to store computed/generated values, to re-use them instead of computing them again.">"cache"</abbr> and pass it to all the "dependants" that need it in that specific request, instead of calling the dependency multiple times for the same request.
+And it will save the returned value in a <abbr title="A utility/system to store computed/generated values, to reuse them instead of computing them again.">"cache"</abbr> and pass it to all the "dependants" that need it in that specific request, instead of calling the dependency multiple times for the same request.
 
 In an advanced scenario where you know you need the dependency to be called at every step (possibly multiple times) in the same request instead of using the "cached" value, you can set the parameter `use_cache=False` when using `Depends`:
 

docs/en/docs/tutorial/handling-errors.md

@@ -248,12 +248,12 @@ In this example, to be able to have both `HTTPException`s in the same code, Star
 from starlette.exceptions import HTTPException as StarletteHTTPException
 ```
 
-### Re-use **FastAPI**'s exception handlers
+### Reuse **FastAPI**'s exception handlers
 
-If you want to use the exception along with the same default exception handlers from  **FastAPI**, You can import and re-use the default exception handlers from `fastapi.exception_handlers`:
+If you want to use the exception along with the same default exception handlers from  **FastAPI**, You can import and reuse the default exception handlers from `fastapi.exception_handlers`:
 
 ```Python hl_lines="2-5  15  21"
 {!../../../docs_src/handling_errors/tutorial006.py!}
 ```
 
-In this example you are just `print`ing the error with a very expressive message, but you get the idea. You can use the exception and then just re-use the default exception handlers.
+In this example you are just `print`ing the error with a very expressive message, but you get the idea. You can use the exception and then just reuse the default exception handlers.