Allow int for ``truncation_limit_lines`` and ``truncation_limit_chars`` in TOML by Pierre-Sassoulas · Pull Request #14692 · pytest-dev/pytest

Pierre-Sassoulas · 2026-07-09T18:24:41Z

The truncation_limit_lines and truncation_limit_chars ini options were registered without a type, defaulting to 'string'. In native TOML config ([tool.pytest]), integer values then raised a TypeError instead of being accepted, despite being numeric limits.

Register both options with type='int' so TOML integer values are accepted (INI string values keep working via the existing int coercion).

Basically #14689 but without unwanted AI to human conversation.

Fixes #14675

bluetech

We can't just change to int, as that would be a breaking change. We need to allow both, unfortunately.

I will write in the issue how I think we can do it.

nicoddemus

Overall nice work.

It is different than the original proposal of using the types directly (str | int vs ("str", "int")), but I suspect this is good enough and aligns well with the original API.

nicoddemus · 2026-07-10T11:00:42Z

+#: a value of any of these types" (e.g. ``("int", "string")``).
+IniType = _IniTypeTag | tuple[_IniTypeTag, ...]
+
+_INI_TYPE_TAGS: tuple[str, ...] = (


Suggested change

_INI_TYPE_TAGS: tuple[str, ...] = (

#: Runtime list tags accepted by :meth:`Parser.addini` for its ``type`` argument.

#: Keep in sync with _IniTypeTag.

_INI_TYPE_TAGS: tuple[str, ...] = (

nicoddemus · 2026-07-10T11:01:04Z


 FILE_OR_DIR = "file_or_dir"

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


Suggested change

#: The string tags accepted by :meth:`Parser.addini` for its ``type`` argument.

#: The string tags accepted by :meth:`Parser.addini` for its ``type`` argument.

#: Keep in sync with _INI_TYPE_TAGS.

nicoddemus · 2026-07-10T11:03:30Z

        if type is None:
            type = "string"
+        tags = type if isinstance(type, tuple) else (type,)
+        assert tags and all(tag in _INI_TYPE_TAGS for tag in tags), type


We probably should use an exception here, given this might be an user-provided value.

asserts should be used for internal checks/consistency only.

nicoddemus · 2026-07-10T11:04:45Z

-    if type in ("paths", "pathlist", "args", "linelist"):
+    if isinstance(type, tuple):
+        # A union has no unambiguous implicit default; require an explicit one.
+        return None


IIUC, None will be used as default, contrary to the comment. Perhaps raise an exception instead?

Address review feedback in pytest-dev#14692: - Replace the tuple-of-tags API with type expressions, as proposed by bluetech in pytest-dev#14675: plain Python types (str, bool, int, float) and unions of them (e.g. `int | str`) are now accepted in addition to the existing string tags. The truncation options are registered with `type=int | str`. - Raise ValueError instead of asserting on an invalid `type` argument, since it is user (plugin) provided. - Raise ValueError when a union type is registered without an explicit default, instead of silently defaulting to None. - Document the _IniTypeTag/_INI_TYPE_TAGS keep-in-sync requirement.

Pierre-Sassoulas · 2026-07-15T05:54:19Z

Thank you for the review ! I think I addressed all comments in 353934c, also I added support for direct int | str instead of ("int", "string").

Pierre-Sassoulas · 2026-07-15T05:56:05Z

Maybe it would be better to separate in two PRs starting by the refactor to allow multiple type though, let me know.

Pierre-Sassoulas · 2026-07-21T19:01:09Z

Depends on #14751

Pierre-Sassoulas · 2026-07-24T15:43:59Z

This is reviewable again since we merged #14751

bluetech

Thanks.

We also need to update the API Reference (which it seems is currently falsely stating type int...)

It would also be nice to audit the other configuration options to see if they need similar treatment, but we can do that separately.

bluetech · 2026-07-27T13:16:19Z

+    max_chars: int = DEFAULT_MAX_CHARS
+
+    @classmethod
+    def from_config(cls, config: Config) -> TruncationBudget:


Since this introduces a cyclic dependency, maybe the previous location is better.

bluetech · 2026-07-27T13:16:58Z

+    def from_config(cls, config: Config) -> TruncationBudget:
+        """Build a budget from the ``truncation_limit_*`` ini options.
+
+        Both options are registered with ``type=int | str`` for


I think this comment belongs on the addini, not here. Can also be shorter 😉

The truncation_limit_lines and truncation_limit_chars options were registered without a type (defaulting to 'string'), so integer values in native TOML config raised a TypeError (pytest-dev#14675). They are now registered with type=int | str, accepting both int and string values in TOML while keeping the string form working for backward compatibility. TruncationBudget.from_config reads the two options and owns default handling: None (option unset) falls back to the DEFAULT_MAX_* limits, which live next to the class; other values are coerced with int(). truncate_if_required short-circuits on verbosity/CI before reading the options at all. 0 still means 'unbounded'; None means 'use default'. Fixes pytest-dev#14675 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The API reference claimed type int while the options were registered as string; the registration is now int | str, so state that in the confval entries and refresh the stale --help transcript accordingly. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

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

bluetech requested changes Jul 9, 2026

View reviewed changes

Pierre-Sassoulas force-pushed the fix-truncation-limit-int-14675 branch 3 times, most recently from 4010bfd to 007af70 Compare July 10, 2026 07:54

nicoddemus approved these changes Jul 10, 2026

View reviewed changes

Pierre-Sassoulas force-pushed the fix-truncation-limit-int-14675 branch from 007af70 to 353934c Compare July 15, 2026 05:51

Pierre-Sassoulas force-pushed the fix-truncation-limit-int-14675 branch from 353934c to 6942da0 Compare July 21, 2026 18:55

Pierre-Sassoulas mentioned this pull request Jul 21, 2026

Accept type expressions in Parser.addini(type=...) #14751

Merged

Pierre-Sassoulas force-pushed the fix-truncation-limit-int-14675 branch from 6942da0 to 501698d Compare July 21, 2026 19:10

Pierre-Sassoulas mentioned this pull request Jul 23, 2026

Fix: Change truncation_limit_lines and chars to accept int in configs #14772

Closed

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

Pierre-Sassoulas force-pushed the fix-truncation-limit-int-14675 branch from 501698d to 5e48fc9 Compare July 24, 2026 15:40

Pierre-Sassoulas requested review from bluetech and nicoddemus July 24, 2026 15:44

bluetech approved these changes Jul 27, 2026

View reviewed changes

Pierre-Sassoulas and others added 2 commits July 27, 2026 23:22

Pierre-Sassoulas force-pushed the fix-truncation-limit-int-14675 branch from 5e48fc9 to 6e02b69 Compare July 28, 2026 04:41

This was referenced Jul 28, 2026

Validate enum-valued configuration options with Literal types #14791

Draft

Accept integer TOML truncation limits #14796

Closed


		FILE_OR_DIR = "file_or_dir"

		#: The string tags accepted by :meth:`Parser.addini` for its ``type`` argument.

	#: The string tags accepted by :meth:`Parser.addini` for its ``type`` argument.
	#: The string tags accepted by :meth:`Parser.addini` for its ``type`` argument.
	#: Keep in sync with _INI_TYPE_TAGS.

Uh oh!

Uh oh!

Conversation

Pierre-Sassoulas commented Jul 9, 2026

Uh oh!

bluetech left a comment

Choose a reason for hiding this comment

Uh oh!

nicoddemus left a comment

Choose a reason for hiding this comment

Uh oh!

nicoddemus Jul 10, 2026

Choose a reason for hiding this comment

Uh oh!

nicoddemus Jul 10, 2026

Choose a reason for hiding this comment

Uh oh!

nicoddemus Jul 10, 2026

Choose a reason for hiding this comment

Uh oh!

nicoddemus Jul 10, 2026

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

Uh oh!

Pierre-Sassoulas commented Jul 15, 2026

Uh oh!

Pierre-Sassoulas commented Jul 21, 2026

Uh oh!

Pierre-Sassoulas commented Jul 24, 2026

Uh oh!

bluetech left a comment

Choose a reason for hiding this comment

Uh oh!

bluetech Jul 27, 2026

Choose a reason for hiding this comment

Uh oh!

bluetech Jul 27, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Pierre-Sassoulas commented Jul 15, 2026 •

edited

Loading