* para **entrada** el `description` **no será requerido**
* para **salida** será **requerido** (y posiblemente `None`, o en términos de JSON, `null`)

### Modelo para Salida en la Documentación { #model-for-output-in-docs }

# Dependencias con yield { #dependencies-with-yield }

FastAPI admite dependencias que realizan algunos <abbr title='a veces también llamado "código de salida", "código de limpieza", "código de teardown", "código de cierre", "código de salida del context manager", etc.'>pasos adicionales después de finalizar</abbr>.

Para hacer esto, usa `yield` en lugar de `return`, y escribe los pasos adicionales (código) después.

/// tip | Consejo

///

## Añadir un modelo de salida { #add-an-output-model }

Podemos en cambio crear un modelo de entrada con la contraseña en texto plano y un modelo de salida sin ella:

{* ../../docs_src/response_model/tutorial003_py310.py hl[9,11,16] *}

Usando `Depends(scope="function")`, el código de salida después de `yield` se ejecuta justo después de que la *path operation function* termina, antes de que la response se envíe de vuelta al cliente.

Y al usar `Depends(scope="request")` (el valor por defecto), el código de salida después de `yield` se ejecuta después de que la response es enviada.

* Puede hacer algo a esa **response** o ejecutar cualquier código necesario.
* Luego devuelve la **response**.

/// note | Detalles Técnicos

Si tienes dependencias con `yield`, el código de salida se ejecutará *después* del middleware.

No podrías obtener este tipo de soporte de editor si estuvieras trabajando directamente con `dict` en lugar de modelos Pydantic.

Pero tampoco tienes que preocuparte por ellos, los `dicts` entrantes se convierten automáticamente y tu salida se convierte automáticamente a JSON también.

## Cuerpos de `dict`s arbitrarios { #bodies-of-arbitrary-dicts }

También puedes declarar un cuerpo como un `dict` con claves de algún tipo y valores de algún otro tipo.

Aun así, en ambas situaciones, es probable que **FastAPI** [siga siendo más rápida](index.md#performance){.internal-link target=_blank} que (o al menos comparable a) tu framework anterior.

### Dependencias { #dependencies }

* <abbr title="Un método de machine learning que usa redes neuronales artificiales con numerosas capas ocultas entre las capas de entrada y salida, desarrollando así una estructura interna completa">Deep Learning</abbr>

### El abbr da una frase completa y una explicación { #the-abbr-gives-a-full-phrase-and-an-explanation }

{* ../../docs_src/pydantic_v1_in_v2/tutorial003_an_py310.py hl[2:3,6,12,21:22] *}

En el ejemplo anterior, el modelo de entrada es un modelo de Pydantic v1 y el modelo de salida (definido en `response_model=ItemV2`) es un modelo de Pydantic v2.

### Parámetros de Pydantic v1 { #pydantic-v1-parameters }

Continuando con el ejemplo anterior, será común tener más de un modelo relacionado.

Esto es especialmente el caso para los modelos de usuario, porque:

* El **modelo de entrada** necesita poder tener una contraseña.
* El **modelo de salida** no debería tener una contraseña.
* El **modelo de base de datos** probablemente necesitaría tener una contraseña hasheada.

/// danger | Peligro