`truncation_limit_lines` and `truncation_limit_chars` should accept integer values in .toml configs

[5j9]

I think in pyproject.toml and pytest.toml, pytest should accept integer values rather than strings. Currently it's the other way around - I get a type error when using integers and have to use strings.

E   TypeError: ...\pyproject.toml: config option 'truncation_limit_lines' expects a string, got int: 1000000

or

E  TypeError: ...\pyproject.toml: config option 'truncation_limit_chars' expects a string, got int: 0

Steps to reproduce:

1. In pyproject.toml add:

[tool.pytest]
truncation_limit_lines = 0
truncation_limit_chars = 0

2. Sample test:

def test_failure():
    assert {1: 2} == {3: 4}

Current behavior:

• Integers cause a TypeError

Expected behavior:

• Integers should be accepted (these are numeric limits)

Environment:
pytest version: 9.1.1, Windows 11

[bluetech]

Due to backward compat, we need to keep supporting string. This means that if we want to allow int, we need to support both.

@RonnyPfannschmidt had a proposal/draft PR to parse the config based on a pydantic-style class with fields and type annotations. I can't find it quickly right now..

I had a simpler more short-term idea, that in addition to the current parser.addini(..., type="int") style, we also allow passing a limited set of type expressions to type, so in the case of this issue we could write type=int | str. It seems like a mostly straightforward enhancement to me, though maybe the devil is in the details.

[bluetech]

Forgot to mention regarding the type expression idea. There are some config keys (mostly logging ones IIRC) which mostly take numeric values but are currently str because there is some extra possible string value. For these cases it would be nice to support int Literal["empty"] forms. Also, for typing this the new typing.TypeForm might come in handy (it's new in Python 3.15 but can be imported from typing_extensions on older versions).