Accept type expressions in Parser.addini(type=...) by Pierre-Sassoulas · Pull Request #14751 · pytest-dev/pytest

Pierre-Sassoulas · 2026-07-21T18:59:24Z

Prior refactor in order to be able to do #14692 cleanly.

addini now accepts plain Python types (str, bool, int, float) and unions of them (e.g. int | str) for its type argument, in addition to the existing string tags, as proposed by bluetech in #14675.

bluetech

Thanks, LGTM!

(As I mentioned in the previous comment, I also think Literal support would be nice for some configs, but that can be done separately).

bluetech · 2026-07-22T09:50:56Z

+    plain Python type.
+    """
+    if isinstance(type_, str) and type_ in _INI_TYPE_TAGS:
+        return cast("_IniTypeTag", type_)


Is the string type needed here (i.e. does replacing with _IniTypeTag not work)?

bluetech · 2026-07-22T09:51:52Z

 FILE_OR_DIR = "file_or_dir"

+#: The string tags accepted by :meth:`Parser.addini` for its ``type`` argument.
+_IniTypeTag = Literal[


Let's add : TypeAlias to these, then it will be automatically upgraded to type statement once that's available.

bluetech · 2026-07-22T09:55:15Z

        if default is NOTSET:
-            default = get_ini_default_for_type(type)
+            if isinstance(ini_type, tuple):
+                # A union has no unambiguous implicit default; require an


I think the exception message is clear enough that the comment is redundant.

bluetech · 2026-07-22T09:58:10Z

I think this is a simple and clear enough extension to the existing mechanism that even if we ever go with something more elaborate like @RonnyPfannschmidt proposed, it won't be a bother.

bluetech · 2026-07-22T10:42:31Z

+        type: _IniTypeTag
+        | type[bool | int | float | str]
+        | types.UnionType


I think this can be written more type-safely as

type: _IniTypeTag | TypeForm[bool | int | float | str] | None = None,

where TypeForm is imported from typing_extensions under if TYPE_CHECKING (added in Python 3.15). It seems to work as intended in mypy at least.

RonnyPfannschmidt · 2026-07-22T12:26:31Z

It's not blocking my ever evading elaboration 😅

A Literal of strings restricts an ini option's value to the given choices, for example type=Literal["auto", "long"]. The choices are shown in the --help output. Since the choices have no unambiguous implicit default, an explicit default is required, as for unions. Suggested by bluetech in the review of pytest-dev#14751. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The Literal of ini option type tags was repeated inline in Parser.addini and get_ini_default_for_type. Name it, and name the full form the type argument accepts, ahead of extending it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

addini now accepts plain Python types (str, bool, int, float) and unions of them (e.g. `int | str`) for its `type` argument, in addition to the existing string tags, as proposed by bluetech in pytest-dev#14675. A union means the option accepts a value of any of its member types: getini tries each member in order and returns the first that accepts the value. In TOML config the native value may be of any member type, and string-based formats (INI files, -o overrides) coerce it to the first member that accepts it. Internally union types are normalized to a tuple of the existing string tags, reusing the per-tag coercion; single-tag registration and lookup are unchanged. An invalid `type` argument raises ValueError instead of asserting, since it is user (plugin) provided, and registering a union type without an explicit default also raises ValueError instead of silently defaulting to None. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

- Annotate the ini type aliases with TypeAlias - Type addini(type=...) with TypeForm instead of type[...] | UnionType, which statically rejects unions of unsupported types - Drop the unneeded string quoting in cast("_IniTypeTag", ...) - Remove a comment redundant with its exception message Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

A Literal of strings restricts an ini option's value to the given choices, for example type=Literal["auto", "long"]. The choices are shown in the --help output. Since the choices have no unambiguous implicit default, an explicit default is required, as for unions. Suggested by bluetech in the review of pytest-dev#14751. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Co-authored-by: Bruno Oliveira <bruno@soliv.dev>

Apply simplification review findings: - Merge the two tag lookup tables in _ini_type_to_tag into one dict and a try/except, dropping the isinstance guards and the cast - Compute get_origin(type) once in addini - Add _ini_type_repr and use it for --help output and the getini error messages, instead of three inline formatting variants (Literal choices are now consistently rendered 'auto' | 'long') - Move the Literal branch from _getini into _getini_value so type interpretation happens in one layer - Merge the two versionadded 9.2 blocks in the addini docstring and drop the redundant second changelog sentence - Tests: hoist the duplicated conftests to class constants, parametrize the invalid-type and Literal cases, and merge the two --help tests into one Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Pierre-Sassoulas · 2026-07-23T14:35:04Z

Tried to cleanup the history while keeping it reviewable following the comments, I think it's ready now. I made the Litteral change I think it makes more sense to do everything at once.

bluetech · 2026-07-23T14:49:21Z

Thanks for adding the Literal support!

I haven't reviewed that part yet, but just from a quick look, I think it doesn't support e.g. int | Literal["foo"]. I think some of our settings would want this (sorry I can't find it right now, I might be wrong).

Ideally, the support would be for any recursive combination of bool, int, float, Literal, str, union and list[...] thereof (the recursive list part might be problematic for ini backward compat though).

However the current support in the PR is fine and above compatible with it don't have to implement it in this PR.

The alias only exists under TYPE_CHECKING, so Sphinx cannot resolve the reference in the rendered Parser.addini signature, failing the docs build (-W with nitpicky). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Pierre-Sassoulas · 2026-07-23T15:28:14Z

There isn't a lot of additional work to do int | Literal["foo"], maybe you're thinking of verbosity (an int with Litteral["auto"] as a possible value, it's currently handled later in

pytest/src/_pytest/config/__init__.py

Lines 2038 to 2051 in a53a4d9

    
           global_level = self.getoption("verbose", default=0) 
        
           assert isinstance(global_level, int) 
        
           if verbosity_type is None: 
        
               return global_level 
        
           ini_name = Config._verbosity_ini_name(verbosity_type) 
        
           if ini_name not in self._parser._inidict: 
        
               return global_level 
        
           level = self.getini(ini_name) 
        
           if level == Config._VERBOSITY_INI_DEFAULT: 
        
               return global_level 
        
           return int(level)

bluetech · 2026-07-23T16:55:56Z

Yes that's the one: https://docs.pytest.org/en/stable/reference/reference.html#confval-verbosity_assertions

bluetech · 2026-07-23T16:56:55Z

Although for backward compat we will have to keep the str in this case and thus the Literal becomes redundant. But that's probably where I got the need for it.

Allows types such as int | Literal["auto"], where a value is accepted if any member accepts it. This is the shape of several existing options that take a number or a special string sentinel. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Pierre-Sassoulas · 2026-07-23T18:06:00Z

Do we still need it for the future ? I pushed what I had. Imo Litteral is better than str in the case it can be used.

bluetech

LGTM, thanks again!

Pierre-Sassoulas added type: enhancement new feature or API change, should be merged into features branch type: refactoring internal improvements to the code skip news used on prs to opt out of the changelog requirement labels Jul 21, 2026

Pierre-Sassoulas mentioned this pull request Jul 21, 2026

Allow int for truncation_limit_lines and truncation_limit_chars in TOML #14692

Open

Pierre-Sassoulas removed the skip news used on prs to opt out of the changelog requirement label Jul 21, 2026

psf-chronographer Bot added the bot:chronographer:provided (automation) changelog entry is part of PR label Jul 21, 2026

Pierre-Sassoulas force-pushed the addini-type-expressions branch from d9a3d92 to 412e21b Compare July 21, 2026 19:10

bluetech approved these changes Jul 22, 2026

View reviewed changes

bluetech reviewed Jul 22, 2026

View reviewed changes

Pierre-Sassoulas marked this pull request as draft July 23, 2026 05:30

Pierre-Sassoulas force-pushed the addini-type-expressions branch from 412e21b to 6c3ff25 Compare July 23, 2026 07:35

nicoddemus requested changes Jul 23, 2026

View reviewed changes

Comment thread src/_pytest/config/argparsing.py Outdated

Comment thread src/_pytest/config/argparsing.py Outdated

This comment was marked as resolved.

Sign in to view

Pierre-Sassoulas force-pushed the addini-type-expressions branch from 47369e5 to 91dc674 Compare July 23, 2026 13:47

Pierre-Sassoulas and others added 6 commits July 23, 2026 16:23

Next version is 9.2 now

78aaf09

Co-authored-by: Bruno Oliveira <bruno@soliv.dev>

Pierre-Sassoulas force-pushed the addini-type-expressions branch from 57ce0f0 to 7f54d20 Compare July 23, 2026 14:33

Pierre-Sassoulas marked this pull request as ready for review July 23, 2026 14:34

doc: Ignore private _IniTypeArg alias in nitpick list

9fffdcd

The alias only exists under TYPE_CHECKING, so Sphinx cannot resolve the reference in the rendered Parser.addini signature, failing the docs build (-W with nitpicky). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

bluetech approved these changes Jul 23, 2026

View reviewed changes

The-Compiler force-pushed the main branch from cb2ee5b to ced9022 Compare July 24, 2026 09:22

Uh oh!

Uh oh!

Conversation

Pierre-Sassoulas commented Jul 21, 2026

Uh oh!

bluetech left a comment

Choose a reason for hiding this comment

Uh oh!

bluetech Jul 22, 2026

Choose a reason for hiding this comment

Uh oh!

bluetech Jul 22, 2026

Choose a reason for hiding this comment

Uh oh!

bluetech Jul 22, 2026

Choose a reason for hiding this comment

Uh oh!

bluetech commented Jul 22, 2026

Uh oh!

bluetech Jul 22, 2026

Choose a reason for hiding this comment

Uh oh!

RonnyPfannschmidt commented Jul 22, 2026

Uh oh!

Uh oh!

Uh oh!

This comment was marked as resolved.

Uh oh!

Pierre-Sassoulas commented Jul 23, 2026

Uh oh!

bluetech commented Jul 23, 2026

Uh oh!

Pierre-Sassoulas commented Jul 23, 2026

Uh oh!

bluetech commented Jul 23, 2026

Uh oh!

bluetech commented Jul 23, 2026

Uh oh!

Pierre-Sassoulas commented Jul 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bluetech left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Pierre-Sassoulas commented Jul 23, 2026 •

edited

Loading