Skip to content

Bump the python-dependencies group across 1 directory with 5 updates - #2

Open
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/pip/python-dependencies-954dc6515b
Open

Bump the python-dependencies group across 1 directory with 5 updates#2
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/pip/python-dependencies-954dc6515b

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Sep 29, 2026 •
edited
Loading

Copy link
Copy Markdown

Bumps the python-dependencies group with 5 updates in the / directory:

Package From To
pytest 8.4.2 9.1.1
pytest-asyncio 0.26.0 1.4.0
ruff 0.15.14 0.17.1
mypy 1.20.2 2.4.0
datamodel-code-generator 0.57.0 0.85.0

Updates pytest from 8.4.2 to 9.1.1

Release notes

Sourced from pytest's releases.

9.1.1

pytest 9.1.1 (2026-06-19)

Bug fixes

  • #14220: Fixed a logic bug in pytest.RaisesGroup which would might cause it to display incorrect "It matches FooError() which was paired with BarError" messages.
  • #14591: Fixed a regression in pytest 9.1.0 which caused overriding a parametrized fixture with an indirect @​pytest.mark.parametrize to fail with "duplicate parametrization of '<fixture name>'".
  • #14606: Fixed list-item typing errors from mypy in @pytest.mark.parametrize <pytest.mark.parametrize ref> argvalues parameter.
  • #14608: Fixed a regression in pytest 9.1.0 where conftest.py files located in <invocation dir>/test* were no longer loaded as initial conftests when invoked without arguments. This could cause certain hooks (like pytest_addoption) in these files to not fire.

9.1.0

pytest 9.1.0 (2026-06-13)

Removals and backward incompatible breaking changes

  • #14533: When using --doctest-modules, autouse fixtures with module, package or session scope that are defined inline in Python test modules (not plugins or conftests) will now possibly execute twice.

    If this is undesirable, move the fixture definition to a conftest.py file if possible.

    Technical explanation for those interested: When using --doctest-modules, pytest possibly collects Python modules twice, once as pytest.Module and once as a DoctestModule (depending on the configuration). Due to improvements in pytest's fixture implementation, if e.g. the DoctestModule collects a fixture, it is now visible to it only, and not to the Module. This means that both need to register the fixtures independently.

Deprecations (removal in next major release)

  • #10819: Added a deprecation warning for class-scoped fixtures defined as instance methods (without @classmethod). Such fixtures set attributes on a different instance than the test methods use, leading to unexpected behavior. Use @classmethod decorator instead -- by yastcher.

    See 10819 and 14011.

  • #12882: Calling request.getfixturevalue() <pytest.FixtureRequest.getfixturevalue> during teardown to request a fixture that was not already requested is now deprecated and will become an error in pytest 10.

    See dynamic-fixture-request-during-teardown for details.

  • #13409: Using non-~collections.abc.Collection iterables (such as generators, iterators, or custom iterable objects) for the argvalues parameter in @pytest.mark.parametrize <pytest.mark.parametrize ref> and metafunc.parametrize <pytest.Metafunc.parametrize> is now deprecated.

    These iterables get exhausted after the first iteration, leading to tests getting unexpectedly skipped in cases such as running pytest.main() multiple times, using class-level parametrize decorators, or collecting tests multiple times.

    See parametrize-iterators for details and suggestions.

  • #13946: The private config.inicfg attribute is now deprecated. Use config.getini() <pytest.Config.getini> to access configuration values instead.

    See config-inicfg for more details.

  • #14004: Passing baseid to ~pytest.FixtureDef or nodeid strings to fixture registration APIs is now deprecated. These are internal pytest APIs that are used by some plugins.

... (truncated)

Commits
  • cf470ec Prepare release version 9.1.1
  • e0c8ce6 Merge pull request #14625 from pytest-dev/patchback/backports/9.1.x/a07c31a97...
  • 1b82d16 Merge pull request #14624 from pytest-dev/patchback/backports/9.1.x/b375b79ec...
  • 501c4bc Merge pull request #14596 from bluetech/doc-classmethod
  • b61f588 Merge pull request #14622 from chrisburr/fix-14608-initial-conftest-test-subdir
  • 9a567e0 [automated] Update plugin list (#14617) (#14618)
  • ef8b299 Merge pull request #14620 from pytest-dev/patchback/backports/9.1.x/680f9f3ed...
  • 66abd07 Merge pull request #14220 from bysiber/fix-stale-iexp-raisesgroup
  • 79fbf93 Merge pull request #14612 from pytest-dev/patchback/backports/9.1.x/974ed48b6...
  • 0d312eb Merge pull request #14611 from bluetech/parametrize-argvalues-typing
  • Additional commits viewable in compare view

Updates pytest-asyncio from 0.26.0 to 1.4.0

Release notes

Sourced from pytest-asyncio's releases.

pytest-asyncio v1.4.0

1.4.0 - 2026-05-26

Deprecated

  • Overriding the event_loop_policy fixture is deprecated. Use the pytest_asyncio_loop_factories hook instead. (#1419)

Added

  • Added the pytest_asyncio_loop_factories hook to parametrize asyncio tests with custom event loop factories.

    The hook returns a mapping of factory names to loop factories, and pytest.mark.asyncio(loop_factories=[...]) selects a subset of configured factories per test. When a single factory is configured, test names are unchanged.

    Synchronous @pytest_asyncio.fixture functions now see the correct event loop when custom loop factories are configured, even when test code disrupts the current event loop (e.g., via asyncio.run() or asyncio.set_event_loop(None)). (#1164)

Changed

  • Improved the readability of the warning message that is displayed when asyncio_default_fixture_loop_scope is unset (#1298)
  • Only import asyncio.AbstractEventLoopPolicy for type checking to avoid raising a DeprecationWarning. (#1394)
  • Updated minimum supported pytest version to v8.4.0. (#1397)

Fixed

  • Fixed a ResourceWarning: unclosed event loop warning that could occur when a synchronous test called asyncio.run() or otherwise unset the current event loop after pytest-asyncio had run an async test or fixture. (#724)

Notes for Downstream Packagers

  • Added dependency on sphinx-tabs >= 3.5 to organize documentation examples into tabs. (#1395)

pytest-asyncio v1.4.0a2

1.4.0a2 - 2026-05-02

Deprecated

  • Overriding the event_loop_policy fixture is deprecated. Use the pytest_asyncio_loop_factories hook instead. (#1419)

Added

  • Added the pytest_asyncio_loop_factories hook to parametrize asyncio tests with custom event loop factories.

    The hook returns a mapping of factory names to loop factories, and pytest.mark.asyncio(loop_factories=[...]) selects a subset of configured factories per test. When a single factory is configured, test names are unchanged on pytest 8.4+.

    Synchronous @pytest_asyncio.fixture functions now see the correct event loop when custom loop factories are configured, even when test code disrupts the current event loop (e.g., via asyncio.run() or asyncio.set_event_loop(None)). (#1164)

Changed

  • Improved the readability of the warning message that is displayed when asyncio_default_fixture_loop_scope is unset (#1298)
  • Only import asyncio.AbstractEventLoopPolicy for type checking to avoid raising a DeprecationWarning. (#1394)

... (truncated)

Commits
  • 6e14cd2 chore: Prepare release of v1.4.0.
  • 4b900fb Build(deps): Bump codecov/codecov-action from 6.0.0 to 6.0.1
  • ab9f632 Build(deps): Bump zipp from 3.23.1 to 4.1.0
  • a56fc77 Build(deps): Bump hypothesis from 6.152.6 to 6.152.8
  • e8bae9b Build(deps): Bump requests from 2.34.0 to 2.34.2
  • fc43340 Build(deps): Bump idna from 3.14 to 3.15
  • 762eaf5 Build(deps): Bump jaraco-functools from 4.4.0 to 4.5.0
  • b62e222 Build(deps): Bump click from 8.3.3 to 8.4.0
  • 9190447 Build(deps): Bump pydantic from 2.13.3 to 2.13.4
  • 82a393c ci: Remove unnecessary debug output.
  • Additional commits viewable in compare view

Updates ruff from 0.15.14 to 0.17.1

Release notes

Sourced from ruff's releases.

0.17.1

Release Notes

Released on 2026-10-15.

Preview features

  • [pycodestyle] Don't treat None, True, or False as keywords (E271-E274) (#29322)

Bug fixes

  • Fix dedent with multiple leading comments (#29382)
  • [flake8-pyi] Detect legacy positional-only parameters in __new__ methods (PYI063) (#28502)
  • [flake8-pyi] Fix false positives on quoted annotations (PYI036) (#29274)
  • [perflint] Avoid invalid comprehension suggestions (PERF401, PERF403) (#29366)

Rule changes

  • Treat more collections and weakref containers as mutable (#29213)

Documentation

  • [flake8-import-conventions] Update default and example aliases (#29333)

Contributors

Install ruff 0.17.1

Install prebuilt binaries via shell script

curl --proto '=https' --tlsv1.2 -LsSf https://releases.astral.sh/github/ruff/releases/download/0.17.1/ruff-installer.sh | sh

Install prebuilt binaries via powershell script

powershell -ExecutionPolicy Bypass -c "irm https://releases.astral.sh/github/ruff/releases/download/0.17.1/ruff-installer.ps1 | iex"

Download ruff 0.17.1

| File | Platform | Checksum |

... (truncated)

Changelog

Sourced from ruff's changelog.

0.17.1

Released on 2026-10-15.

Preview features

  • [pycodestyle] Don't treat None, True, or False as keywords (E271-E274) (#29322)

Bug fixes

  • Fix dedent with multiple leading comments (#29382)
  • [flake8-pyi] Detect legacy positional-only parameters in __new__ methods (PYI063) (#28502)
  • [flake8-pyi] Fix false positives on quoted annotations (PYI036) (#29274)
  • [perflint] Avoid invalid comprehension suggestions (PERF401, PERF403) (#29366)

Rule changes

  • Treat more collections and weakref containers as mutable (#29213)

Documentation

  • [flake8-import-conventions] Update default and example aliases (#29333)

Contributors

0.17.0

Released on 2026-10-09.

The executables in our macOS and Windows release archives and ruff wheels are now code-signed. macOS executables are signed with an Apple Developer ID certificate and notarized by Apple. Windows executables have timestamped Authenticode signatures from Azure Artifact Signing. This enables verification of the release publisher and binary integrity, supports publisher-based allowlisting, and should reduce security warnings and antivirus false positives.

Breaking changes

  • Update the default and latest Python versions for 3.15 (#28792)

    Ruff now defaults to Python 3.11 instead of 3.10 when no Python version is configured through target-version or requires-python. When checking for syntax errors without a configured Python version, Ruff now defaults to Python 3.15

... (truncated)

Commits
  • 4683270 Bump version to 0.17.1 (#29420)
  • 3514027 [ty] Update typing conformance suite pin (#29417)
  • 8294556 Update referenced PR security-review workflow (#29237)
  • d1e1b1f [ty] Preserve recursive aliases when rebuilding intersections (#29057)
  • 9352615 [perflint] Avoid invalid comprehension suggestions (PERF401, PERF403) (...
  • 83a3afc Fix dedent with multiple leading comments (#29382)
  • b42a873 [ty] Clarify object attribute write-contract rationale (#29384)
  • d01678e [ty] Clarify object attribute write-contract rationale (#29384)
  • 355b42a [ty] Avoid writable override contracts from object (#29373)
  • e26e6d2 [ty] Collect intersection inference through constraint relations (#28677)
  • Additional commits viewable in compare view

Updates mypy from 1.20.2 to 2.4.0

Changelog

Sourced from mypy's changelog.

Mypy Release Notes

Next Release

Mypy 2.4

We've just uploaded mypy 2.4.0 to the Python Package Index (PyPI). Mypy is a static type checker for Python. This release includes new features, performance improvements and bug fixes. You can install it as follows:

python3 -m pip install -U mypy

You can read the full documentation for this release on Read the Docs.

Python 3.15 Support

Mypy 2.4 supports running on Python 3.15 and type checking most Python 3.15 features. This includes the new builtin sentinel type for sentinel values (PEP 661), which mypy now supports (see below for details). Lazy imports (PEP 810) and unpacking in comprehensions (PEP 798) are also supported. Closed TypedDicts (PEP 728) have been supported since mypy 2.2, but the extra_items TypedDict argument, also introduced in PEP 728, is still unsupported. Support for extra_items will be added in a future mypy release.

Native Parser Enabled by Default

Mypy now uses the new native parser by default. It's based on the Ruff parser, and it's significantly faster than the legacy parser, which uses the stdlib ast module. The native parser also has other benefits:

  • You can target newer Python versions and use recent Python syntax even when running mypy on an older Python version. For example, you can use --python-version 3.15 when running mypy on Python 3.14.
  • Stub files can use syntax that is newer than the target Python version. For example, stubs can use the PEP 695 generic class syntax (class Box[T]: ...) when running on or targeting Python 3.10.
  • Parallel type checking requires the native parser.

The legacy parser is still available through --no-native-parser, or native_parser = False in the config file (native_parser = false under [tool.mypy] in pyproject.toml). We are planning to remove the legacy parser in early 2027. If you run into a problem with the native parser, please report it on the issue tracker.

Unlike the legacy parser, the native parser doesn't support type comments for variables defined by for and with statements. These type comments are silently ignored, and the types of the variables are

... (truncated)

Commits

Updates datamodel-code-generator from 0.57.0 to 0.85.0

Release notes

Sourced from datamodel-code-generator's releases.

0.85.0

Breaking Changes

Error Handling Changes

  • Output encoding failures now raise Error instead of raw codec exceptions - Generated output, model metadata from --emit-model-metadata, and API target package files are now encoded before anything is written. If the chosen --encoding / encoding cannot encode the text, generate() raises datamodel_code_generator.Error with the message Unable to encode output using encoding '...': ... instead of letting UnicodeEncodeError escape. The CLI now prints this as a single error line and exits with code 2 instead of showing a traceback. Python API callers that caught UnicodeEncodeError or UnicodeError need to catch Error instead. Also, when one module of a modular output fails to encode, no files are written; before, earlier modules could be written before the failure (#4615)
  • Unknown or non-text encodings are rejected up front with Error - generate() now checks the encoding option during config preparation, before any input is read or any output path is created. An unknown encoding such as nosuch, or a codec that is not a text encoding such as hex, now raises datamodel_code_generator.Error (CLI exit code 2, one-line message) instead of a raw LookupError raised later. Code that caught LookupError for a bad encoding must catch Error instead (#4615)
  • Explicit names are now checked as identifiers of the target Python version - This applies to --class-name, --class-name-prefix, --class-name-suffix, --special-field-name-prefix, --model-name-map values and explicit field aliases. It also applies to client and FastAPI generation settings such as package, model_package, resource namespaces, operation, parameter and router names, and protocol helper names. These are now checked against the identifier rules of --target-python-version, not the running interpreter, so a name that uses characters only a newer Python accepts is now rejected (for example with E_CONFIG_VALUE or an invalid identifier error) when targeting an older Python, even if the running interpreter accepts it (#4790)
  • Generation now fails when an override or schema import names a standard-library type the target lacks - A standard-library type named by --type-overrides, customTypePath or x-python-import (including its qualname and native-field paths) that does not exist in the target Python version now stops generation with TYPE is unavailable for target Python X.Y. Examples are enum.StrEnum for 3.10, pathlib.types.PathInfo for 3.13, builtins.frozendict for 3.14 and pathlib.DirEntryInfo for 3.15. Before this change the import was written as given and generation succeeded. The check runs only when the final output imports the type. To fix this, raise --target-python-version or use --import-overrides to point the import at a backport module, for example --import-overrides '{"StrEnum": "backports.strenum"}'. (#4788)

Code Generation Changes

  • Non-ASCII identifiers now follow the target Python version's Unicode rules - Field names, class names, enum member names, module names, alias generator output (to_camel, to_pascal, to_snake), OpenAPI operation model names and the builtin formatter's import ordering are now worked out from Unicode tables for --target-python-version. Those tables cover identifier characters, \w, numeric characters, case mappings and NFKC normalization. Before, these names came from the str, re and unicodedata behaviour of the interpreter running datamodel-codegen. ASCII names are unaffected, but output for non-ASCII schema names can change when the running interpreter's Unicode version differs from the target's. For example, a property 京都 (U+4EAC is numeric from Python 3.13) used to become field_京都 when generated on Python 3.13 or later. It is now emitted as 京都 for targets up to 3.12, and the reverse happens when generating on an older Python for a 3.13 or later target. Likewise, --capitalise-enum-members no longer turns ɤ into Ɤ for targets older than 3.14, even when running on Python 3.14. Regenerate and review models whose names contain non-ASCII characters, because renamed fields and members break code that refers to them (#4790)
  • Newer typing names from type overrides and schema import paths now come from typing_extensions - Standard-library typing or collections.abc names given through --type-overrides, customTypePath or x-python-import are now resolved against --target-python-version. If the name is newer than the target, the import now comes from typing_extensions. For example, typing.LiteralString and collections.abc.Buffer with target 3.10 now produce from typing_extensions import Buffer, LiteralString instead of importing them from typing and collections.abc as before. Projects that compare generated output, or that do not have typing_extensions installed, will see different imports. (#4788)
  • Builtin formatter groups standard library imports by target Python version - With --formatters builtin, whether an import goes in the standard library section or the third party section now depends on the standard library modules of --target-python-version. When no target is given, the minimum supported target, 3.10, is used. Before this change, the formatter used sys.stdlib_module_names of the running interpreter. When the running Python differs from the target, imports in generated files can move to a different section. For example, tomllib is grouped as third party when targeting 3.10, distutils is grouped as standard library when targeting 3.10 even on a newer interpreter, and sre_parse becomes third party while profiling becomes standard library when targeting 3.15 (#4791)
  • Builtin formatter places each module of a multi-module import in its own section - With --formatters builtin, an import a, b, c statement that names modules from different categories (standard library, third party, first party) now puts each module in its own section, as isort does. Before, all modules from that statement went into the section of the highest-priority module among them, so the order of generated imports can change (#4791)
  • Reuse model now deduplicates models whose referenced names start with non-ASCII letters - With --reuse-model, model names that start with characters beyond ASCII (for example Ñumber or Ölen) are now masked as whole identifiers when models are compared. Models that are identical except for such references are now reused as subclasses (for example class Distance(Speed): pass) instead of being generated as separate duplicate classes. This matches how ASCII names already worked. As a result, some previously generated duplicate classes and their numbered names may no longer appear in the output (#4791)

What's Changed

New Contributors

Full Changelog: datamodel-code-generator/datamodel-code-generator@0.84.0...0.85.0

0.84.0

Highlights

Experimental: FastAPI server and Python client generation

Besides the models, datamodel-code-generator can now generate a FastAPI server package and a typed HTTPX2 client from one OpenAPI document. Both are new in 0.84.0 and experimental: options, templates and the generated packages may change in later releases (they are listed in the experimental registry with since_version 0.84.0). The generated code uses your generated models as its runtime contract: they validate requests and responses, and the generated server reads its packaged copy of the OpenAPI document only to serve it.

Get started:

# FastAPI server package in app/server/ (mkdir app && touch app/__init__.py first)
</tr></table>

... (truncated)

Changelog

Sourced from datamodel-code-generator's changelog.

0.85.0 - 2026-10-16

Breaking Changes

Error Handling Changes

  • Output encoding failures now raise Error instead of raw codec exceptions - Generated output, model metadata from --emit-model-metadata, and API target package files are now encoded before anything is written. If the chosen --encoding / encoding cannot encode the text, generate() raises datamodel_code_generator.Error with the message Unable to encode output using encoding '...': ... instead of letting UnicodeEncodeError escape. The CLI now prints this as a single error line and exits with code 2 instead of showing a traceback. Python API callers that caught UnicodeEncodeError or UnicodeError need to catch Error instead. Also, when one module of a modular output fails to encode, no files are written; before, earlier modules could be written before the failure (#4615)
  • Unknown or non-text encodings are rejected up front with Error - generate() now checks the encoding option during config preparation, before any input is read or any output path is created. An unknown encoding such as nosuch, or a codec that is not a text encoding such as hex, now raises datamodel_code_generator.Error (CLI exit code 2, one-line message) instead of a raw LookupError raised later. Code that caught LookupError for a bad encoding must catch Error instead (#4615)
  • Explicit names are now checked as identifiers of the target Python version - This applies to --class-name, --class-name-prefix, --class-name-suffix, --special-field-name-prefix, --model-name-map values and explicit field aliases. It also applies to client and FastAPI generation settings such as package, model_package, resource namespaces, operation, parameter and router names, and protocol helper names. These are now checked against the identifier rules of --target-python-version, not the running interpreter, so a name that uses characters only a newer Python accepts is now rejected (for example with E_CONFIG_VALUE or an invalid identifier error) when targeting an older Python, even if the running interpreter accepts it (#4790)
  • Generation now fails when an override or schema import names a standard-library type the target lacks - A standard-library type named by --type-overrides, customTypePath or x-python-import (including its qualname and native-field paths) that does not exist in the target Python version now stops generation with TYPE is unavailable for target Python X.Y. Examples are enum.StrEnum for 3.10, pathlib.types.PathInfo for 3.13, builtins.frozendict for 3.14 and pathlib.DirEntryInfo for 3.15. Before this change the import was written as given and generation succeeded. The check runs only when the final output imports the type. To fix this, raise --target-python-version or use --import-overrides to point the import at a backport module, for example --import-overrides '{"StrEnum": "backports.strenum"}'. (#4788)

Code Generation Changes

  • Non-ASCII identifiers now follow the target Python version's Unicode rules - Field names, class names, enum member names, module names, alias generator output (to_camel, to_pascal, to_snake), OpenAPI operation model names and the builtin formatter's import ordering are now worked out from Unicode tables for --target-python-version. Those tables cover identifier characters, \w, numeric characters, case mappings and NFKC normalization. Before, these names came from the str, re and unicodedata behaviour of the interpreter running datamodel-codegen. ASCII names are unaffected, but output for non-ASCII schema names can change when the running interpreter's Unicode version differs from the target's. For example, a property 京都 (U+4EAC is numeric from Python 3.13) used to become field_京都 when generated on Python 3.13 or later. It is now emitted as 京都 for targets up to 3.12, and the reverse happens when generating on an older Python for a 3.13 or later target. Likewise, --capitalise-enum-members no longer turns ɤ into Ɤ for targets older than 3.14, even when running on Python 3.14. Regenerate and review models whose names contain non-ASCII characters, because renamed fields and members break code that refers to them (#4790)
  • Newer typing names from type overrides and schema import paths now come from typing_extensions - Standard-library typing or collections.abc names given through --type-overrides, customTypePath or x-python-import are now resolved against --target-python-version. If the name is newer than the target, the import now comes from typing_extensions. For example, typing.LiteralString and collections.abc.Buffer with target 3.10 now produce from typing_extensions import Buffer, LiteralString instead of importing them from typing and collections.abc as before. Projects that compare generated output, or that do not have typing_extensions installed, will see different imports. (#4788)
  • Builtin formatter groups standard library imports by target Python version - With --formatters builtin, whether an import goes in the standard library section or the third party section now depends on the standard library modules of --target-python-version. When no target is given, the minimum supported target, 3.10, is used. Before this change, the formatter used sys.stdlib_module_names of the running interpreter. When the running Python differs from the target, imports in generated files can move to a different section. For example, tomllib is grouped as third party when targeting 3.10, distutils is grouped as standard library when targeting 3.10 even on a newer interpreter, and sre_parse becomes third party while profiling becomes standard library when targeting 3.15 (#4791)
  • Builtin formatter places each module of a multi-module import in its own section - With --formatters builtin, an import a, b, c statement that names modules from different categories (standard library, third party, first party) now puts each module in its own section, as isort does. Before, all modules from that statement went into the section of the highest-priority module among them, so the order of generated imports can change (#4791)
  • Reuse model now deduplicates models whose referenced names start with non-ASCII letters - With --reuse-model, model names that start with characters beyond ASCII (for example Ñumber or Ölen) are now masked as whole identifiers when models are compared. Models that are identical except for such references are now reused as subclasses (for example class Distance(Speed): pass) instead of being generated as separate duplicate classes. This matches how ASCII names already worked. As a result, some previously generated duplicate classes and their numbered names may no longer appear in the output (#4791)

What's Changed

New Contributors

Full Changelog: datamodel-code-generator/datamodel-code-generator@0.84.0...0.85.0

0.84.0 - 2026-10-15

Highlights

Experimental: FastAPI server and Python client generation

Besides the models, datamodel-code-generator can now generate a FastAPI server package and a typed HTTPX2 client from one OpenAPI document. Both are new in 0.84.0 and experimental: options, templates and the generated packages may change in later releases (they are listed in the experimental registry with since_version 0.84.0). The generated code uses your generated models as its runtime contract: they validate requests and responses, and the generated server reads its packaged copy of the OpenAPI document only to serve it.

... (truncated)

Commits
  • 723f9e3 Check type overrides, customTypePath and x-python-import against the target P...
  • c20e85b Take the target Python of model type decisions from the field configuration (...
  • 7fa825d Group the builtin formatter's imports by the target Python's standard library...
  • bfc6e0a Follow the target Python's Unicode version for generated names (#4790)
  • 90a8690 Read builtin names for field collisions from the static target table (#4786)
  • 8733b04 Check property-name regexes and nested $schema in the payload regex filter (#...
  • 000d411 Run the FastAPI server e2e on Python 3.15 in CI (#4780)
  • fa5c481 Document Python 3.15 targets (#4773)
  • 26b6d0b Add 20261015 presets with Python 3.15 targets (#4772)
  • 494a10b Name the black requirement when black cannot format the target (#4771)
  • Additional commits viewable in compare view

@dependabot dependabot Bot added the dependencies Pull requests that update a dependency file label Sep 29, 2026
@dependabot
dependabot Bot requested a review from troycorbinz as a code owner September 29, 2026 18:05
@dependabot dependabot Bot added python Pull requests that update python code dependencies Pull requests that update a dependency file labels Sep 29, 2026
@dependabot dependabot Bot changed the title build(deps-dev): bump the python-dependencies group with 5 updates Bump the python-dependencies group across 1 directory with 5 updates Oct 6, 2026
@dependabot
dependabot Bot force-pushed the dependabot/pip/python-dependencies-954dc6515b branch from 80ea38a to c322f7b Compare October 6, 2026 06:15
@dependabot
dependabot Bot force-pushed the dependabot/pip/python-dependencies-954dc6515b branch from c322f7b to 83da7e5 Compare October 14, 2026 16:15
@dependabot
Bump the python-dependencies group across 1 directory with 5 updates
914305b 
Bumps the python-dependencies group with 5 updates in the / directory:

| Package | From | To |
| --- | --- | --- |
| [pytest](https://github.com/pytest-dev/pytest) | `8.4.2` | `9.1.1` |
| [pytest-asyncio](https://github.com/pytest-dev/pytest-asyncio) | `0.26.0` | `1.4.0` |
| [ruff](https://github.com/astral-sh/ruff) | `0.15.14` | `0.17.1` |
| [mypy](https://github.com/python/mypy) | `1.20.2` | `2.4.0` |
| [datamodel-code-generator](https://github.com/datamodel-code-generator/datamodel-code-generator) | `0.57.0` | `0.85.0` |



Updates `pytest` from 8.4.2 to 9.1.1
- [Release notes](https://github.com/pytest-dev/pytest/releases)
- [Changelog](https://github.com/pytest-dev/pytest/blob/main/CHANGELOG.rst)
- [Commits](pytest-dev/pytest@8.4.2...9.1.1)

Updates `pytest-asyncio` from 0.26.0 to 1.4.0
- [Release notes](https://github.com/pytest-dev/pytest-asyncio/releases)
- [Commits](pytest-dev/pytest-asyncio@v0.26.0...v1.4.0)

Updates `ruff` from 0.15.14 to 0.17.1
- [Release notes](https://github.com/astral-sh/ruff/releases)
- [Changelog](https://github.com/astral-sh/ruff/blob/main/CHANGELOG.md)
- [Commits](astral-sh/ruff@0.15.14...0.17.1)

Updates `mypy` from 1.20.2 to 2.4.0
- [Changelog](https://github.com/python/mypy/blob/master/CHANGELOG.md)
- [Commits](python/mypy@v1.20.2...v2.4.0)

Updates `datamodel-code-generator` from 0.57.0 to 0.85.0
- [Release notes](https://github.com/datamodel-code-generator/datamodel-code-generator/releases)
- [Changelog](https://github.com/datamodel-code-generator/datamodel-code-generator/blob/main/CHANGELOG.md)
- [Commits](datamodel-code-generator/datamodel-code-generator@0.57.0...0.85.0)

---
updated-dependencies:
- dependency-name: datamodel-code-generator
  dependency-version: 0.83.0
  dependency-type: direct:development
  update-type: version-update:semver-minor
  dependency-group: python-dependencies
- dependency-name: mypy
  dependency-version: 2.3.1
  dependency-type: direct:development
  update-type: version-update:semver-major
  dependency-group: python-dependencies
- dependency-name: pytest
  dependency-version: 9.1.1
  dependency-type: direct:development
  update-type: version-update:semver-major
  dependency-group: python-dependencies
- dependency-name: pytest-asyncio
  dependency-version: 1.4.0
  dependency-type: direct:development
  update-type: version-update:semver-major
  dependency-group: python-dependencies
- dependency-name: ruff
  dependency-version: 0.16.9
  dependency-type: direct:development
  update-type: version-update:semver-minor
  dependency-group: python-dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot
dependabot Bot force-pushed the dependabot/pip/python-dependencies-954dc6515b branch from 83da7e5 to 914305b Compare October 20, 2026 06:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@troycorbinz troycorbinz Awaiting requested review from troycorbinz troycorbinz is a code owner

Assignees

No one assigned

Labels

dependencies Pull requests that update a dependency file python Pull requests that update python code

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants