Deprecate parameter names that are: not a Python identifier, or a Python Keyword, or not lower-cased

[kdeldycke]

This PR prepares the ground for #3827, which is going to refuse parameter names that are not valid Python identifiers.

This add DeprecationWarning that detect when Parameter, Argument or Option gets a name that will be not allowed in the future 9.0.0 release:

• a parameter that is not a Python identifier (check against str.identifier)
• a parameter that is a Python keyword (check against keyword.iskeyword)
• an option name that is nor lower-cased

This PR also copy the majority of tests that were originally proposed in #3827, so the behavior of the name is locked down and frozen. This will prevent tweaking or introducing regressions during the full 8.x cycle.

This PR also inaugurate the 8.6.0 release on main.

Historical details

Of course, I fucked-up the same way I fucked-up 2 months ago with #3701 , when juggling between main and stable branches made me push to stable. 😫

So:

• I pushed by mistake e2bddbc
• I reverted my mistake on stable with d036881
• And this PR is what it should have been all along

Anyway, this was resolved by resyncing both branches with #3876 .

[davidism]

What do you think, should we also check keyword.iskeyword? Might be good to warn about it and see if anything comes up.

[kdeldycke]

What do you think, should we also check keyword.iskeyword? Might be good to warn about it and see if anything comes up.

Ah. That might be a good idea: test drive that check during a long 8.x cycle and see if it show up... If I implement this, what kind of severity should it triggers? A DeprecationWarning like non-Python-IDs ?

[davidism]

Deprecation seems fine. Like I said in the other thread, it could be more disruptive, but it also seems to match the intention of the str.isidentifier check.

[kdeldycke]

Just implemented the double isidentifier() / iskeyword() deprecation check in a common _check_name_is_usable() internal function. The later is maybe a bit too verbose as I distinguished the 2 cases and reused the deprecation explanation from docs/upgrade-guides.md. Can make it way smaller if you want to.

This is ready to be reviewed for eventual merge.

[Rowlando13]

@kdeldycke this should merge into main. I don't we should issue new deprecations on bug fix versions.

[kdeldycke]

@kdeldycke this should merge into main. I don't we should issue new deprecations on bug fix versions.

OK make sense. So I retargeted the main branch, added a new commit in this PR to inaugurate the 8.6.0 release and updated the doc to target that release. And this time I hope I did not made any mistake juggling with the two branches... 🫣