Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Reject keyword argument None with .none(false) #2611

Merged
merged 5 commits into from
Oct 20, 2020

Conversation

potpath
Copy link
Contributor

@potpath potpath commented Oct 20, 2020

Description

Demo a failing test case where passing keyword as None to py::arg("a").none(false) is still accepted.

m.def("no_none", [](T*){}, py::arg("a").none(false));
m.no_none(None)    # ok raises `TypeError` 
m.no_none(a=None)  # not ok, this is accepted

Suggested changelog entry:

N/A.
This PR is to show a failing test case that can be used as a starting point.

@potpath potpath changed the title demo kwarg with none(false) Demo passing keyword argument as None with .none(false) Oct 20, 2020
@YannickJadoul
Copy link
Collaborator

Thanks for reporting, @potpath! Weird that this was never encountered before.

I've pushed a fix to your branch that hopefully fixes this! :-)

@@ -628,26 +628,30 @@ class cpp_function : public function {
bool copied_kwargs = false;

for (; args_copied < num_args; ++args_copied) {
const auto &arg = func.args[args_copied];
const auto &arg_rec = func.args[args_copied];
Copy link
Collaborator

Choose a reason for hiding this comment

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

This rename is, strictly speaking, unrelated, but to increase conformity with the naming in step // 1. above, and to more clearly indicate the type, I renamed it.

@YannickJadoul YannickJadoul marked this pull request as ready for review October 20, 2020 11:06
@YannickJadoul YannickJadoul changed the title Demo passing keyword argument as None with .none(false) fix: Reject keyword argument None with .none(false) Oct 20, 2020
@@ -404,6 +404,19 @@ def test_accepts_none(msg):
assert m.ok_none4(None) == -1
assert m.ok_none5(None) == -1

with pytest.raises(TypeError) as excinfo:
m.no_none_kw(None)
Copy link
Collaborator

Choose a reason for hiding this comment

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

no_none_kw seems to suggest that one keyword arguments with None as the value are forbidden. At least that's how I'm reading it.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Also after the others, no_none{1..5} and ok_none{1..5}?
Any suggestions? no_none_as_kw?

Copy link
Collaborator

Choose a reason for hiding this comment

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

no_none sounds good.

@henryiii
Copy link
Collaborator

henryiii commented Oct 20, 2020

Let's add a change log entry too, unless this worked in 2.5. Might also grep and make sure this didn't have some other use or attempt to use elsewhere, and also make sure it's mentioned in the docs.

@YannickJadoul
Copy link
Collaborator

Let's add a change log entry too, unless this worked in 2.5.

Right, I overlooked that by building further on this existing PR.

Might also grep and make sure this didn't have some other use or attempt to use elsewhere, and also make sure it's mentioned in the docs.

Where would it? Tests pass, so I assume this wasn't tested or considered before?

@YannickJadoul
Copy link
Collaborator

Right, I overlooked that by building further on this existing PR.

Fine to log under "Smaller or developer focused features and fixes:"?

Copy link
Collaborator

@rwgk rwgk left a comment

Choose a reason for hiding this comment

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

If this can still be included in 2.6.0 that would be great, but only if it doesn't cause a lot of extra work.

@YannickJadoul YannickJadoul added this to the v2.6.0 milestone Oct 20, 2020
@YannickJadoul
Copy link
Collaborator

but only if it doesn't cause a lot of extra work.

Good point, but I don't think so; I think it's ready. To me, this is almost purely a bug fix (since I don't think we mention in the docs that this only works for positional arguments?).

@henryiii
Copy link
Collaborator

I think it's fine with me.

@YannickJadoul YannickJadoul merged commit 6edd0e6 into pybind:master Oct 20, 2020
@potpath
Copy link
Contributor Author

potpath commented Oct 21, 2020

Thank you everyone for this prompt fix!

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.

5 participants