[RFC] Exempt input type and value validation from BC Break policy

3 months ago by Pratik Bhujel — view source — reply

unread

Hi all,

Thanks for the RFC. I have a real‑world example that seems to fit this
“input validation” category and wanted to sanity‑check it with you.

I opened PR #21319 to promote a few ext/snmp invalid‑input warnings to
ValueError (only for invalid inputs). Valid inputs behave the same; the
goal is just to make errors catchable and consistent with other extensions.

If this RFC passes, would a change like that be OK without a separate
per‑function RFC? And are there any expectations you’d want contributors to
follow (tests, deprecation note, minor vs major timing)?

Happy to share more details if needed.

Thanks,
Pratik

2 months ago by Gina P. Banyard — view source — reply

unread

Hi all,

Thanks for the RFC. I have a real‑world example that seems to fit this “input validation” category and wanted to sanity‑check it with you.

I opened PR #21319 to promote a few ext/snmp invalid‑input warnings to ValueError (only for invalid inputs). Valid inputs behave the same; the goal is just to make errors catchable and consistent with other extensions.

If this RFC passes, would a change like that be OK without a separate per‑function RFC? And are there any expectations you’d want contributors to follow (tests, deprecation note, minor vs major timing)?

Happy to share more details if needed

Correct.
The whole objective of the RFC is to exempt these sorts of sanity checks from the BC promise.
So if this policy RFC is accepted this could land in the next minor version with the adequate tests.
Note that error conditions that cannot be determined statically (e.g. a non-existing file) are always issued as E_WARNINGs currently and never promoted to an exception.

Best regards,
Gina P. Banyard