Improvement for Parser.addini to facilite parsing of 'int' and 'float' values

[harmin-parra]

Implements #11381
parsing of int and float configuration values from the ini files has been improved

[nicoddemus]

Thanks @harmin-parra for the PR!

Left some tweaks to the docs, otherwise LGTM!

[harmin-parra]

There are still some mypy errors that I have no idea how to resolve

[nicoddemus]

Awesome, thanks!

I will leave it open for a few days to give others a chance to review.

[The-Compiler]

I think all those casts in config/__init__.py are incorrect and are hiding bugs.

A pyproject.toml with:

[tool.pytest.ini_options]
int_value = [3]

now causes

        elif type == "int":
            # value = cast(str, value)
            try:
>               return int(value)
                       ^^^^^^^^^^
E               TypeError: int() argument must be a string, a bytes-like object or a real number, not 'list'

I suspect (but haven't tried) that passing an int/float for a paths option will fail in a similar way.

We should probably do some additional validation that the input-type is correct, and raise an exception including the option name if not.

[nicoddemus]

@The-Compiler I agree.

Currently it is only catching ValueError, perhaps it might be enough to catch TypeError too.

[The-Compiler]

That would still need a cast that's actually not true to appease mypy. IMHO, an explicit:

if not isinstance(value, (str, int)):
    raise TypeError(f"Expected str or int for option {name} of type integer, but got: {value!r} ({type(value)})")

or so would:

• Make mypy happy (I think?) without needing a cast that's not actually true
• Give a nicer error message and information to the user
• Make sure we don't do any other operations withe the value that might raise e.g. AttributeError rather than TypeError (but we would not statically catch because we lied to mypy)
• Avoid confusion for others reading the code later because we cast a value to a str when it actually isn't

[nicoddemus]

Sounds good.