Skip to content

Do some normalization of error messages from argument checking - #16038

Open
dcbaker wants to merge 18 commits into
mesonbuild:masterfrom
dcbaker:submit/typed-args-normalize
Open

Do some normalization of error messages from argument checking#16038
dcbaker wants to merge 18 commits into
mesonbuild:masterfrom
dcbaker:submit/typed-args-normalize

Conversation

@dcbaker

@dcbaker dcbaker commented Jul 27, 2026

Copy link
Copy Markdown
Member

This is ground work for a larger set of work to clean up argument validation.

There's also a few cases of making use of typed_kwargs and typed_pos_args for checking where it was previously being done by open coding.

dcbaker added 16 commits July 27, 2026 17:06
All of this can be handled by typed_kwargs instead.
this gives more consistent output between them.
This allows us to use slots easily, which reduces our memory usage. It
also allows us to implement `evolve()` in terms of
`dataclasses.replace`, which simplifies our work considerably.
…cated_values

This allows writing simpler descriptions when adding or removing
multiples types.
Including the new tuple of types support.
The problem for this function is it basically has two overloaded
signatures:
(name: str, ...sources: str | File)
()

This is really difficult to model for `typed_pos_args`, because optional
arguments and variadic arguments are inherently ambiguous. We can,
however, use variadic arguments and then narrow the allowed type for the
first argument if it's given.
@dcbaker
dcbaker force-pushed the submit/typed-args-normalize branch from 006a275 to 6821d80 Compare July 27, 2026 17:19
@bonzini bonzini added this to the 1.13 milestone Jul 31, 2026
else:
shouldbe = f'"{type_.__name__}"'
raise InvalidArguments(f'{name} argument {i} was of type "{type(arg).__name__}" but should have been {shouldbe}')
raise InvalidArguments(f'{name} argument {i} was of type "{_raw_description(arg)}" but should have been {_types_description(type_)}')

@dnicolodi dnicolodi Jul 31, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason to remove the double quotes around {_types_description(type_)}? I find having the quotes around the actual type but not around the expected type a distracting asymmetry.

candidates.append(t.__name__)
shouldbe = 'one of: ' if len(candidates) > 1 else ''
shouldbe += ', '.join(candidates)
shouldbe += ', '.join(f'"{c}"' for c in candidates)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Never mind, the quotes are coming back here...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants