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 invalid specification of default_value without regard to default_value_type #1631

Merged
merged 3 commits into from
Apr 20, 2022

Conversation

mdickinson
Copy link
Member

This is a two-part fix for #1629:

  • Part 1: fix ctraits.c to validate the input to set_default_value in the case where the given default value type is DefaultValue.callable_and_args. This fixes the segfault reported in Cloned TraitTypes don't properly account for callable_and_args defaults #1629, replacing it with a more scrutable Python-level exception.
  • Part 2: in the TraitType.clone base class implementation, when we set a default value, also set the default value type to be consistent with that default value. This still leaves open the possibility for TraitType subclasses to do their own thing in their clone methods (and in particular, the List, Dict and Set trait types will probably want to take advantage of that - see Trait inheritance doesn't work as expected for List traits #1630).

Checklist

  • Tests
  • Update API reference (docs/source/traits_api_reference) N/A
  • Update User manual (docs/source/traits_user_manual) N/A
  • Update type annotation hints in traits-stubs N/A

traits/ctraits.c Outdated Show resolved Hide resolved
Copy link
Contributor

@corranwebster corranwebster left a comment

Choose a reason for hiding this comment

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

This looks like it resolves the issue.

@@ -3064,6 +3064,22 @@ _trait_set_default_value(trait_object *trait, PyObject *args)
return NULL;
Copy link
Contributor

Choose a reason for hiding this comment

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

this is tangential but while looking up the difference between PyErr_Format and PyErr_SetString, I came across the fact that PyErr_Format returns NULL - so we don't need to explicitly return NULL here so we can do return PyErr_Format(...). Right? Or is the convention not to do so?

Ref https://docs.python.org/3/c-api/exceptions.html#c.PyErr_Format

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, we could! Not in this PR, but I'd be happy to look at a PR that made this and similar cleanups across ctraits.c.

@mdickinson mdickinson merged commit dc59b5c into main Apr 20, 2022
@mdickinson mdickinson deleted the fix-1629 branch April 20, 2022 07:19
mdickinson added a commit that referenced this pull request Aug 9, 2022
…value_type (#1631)

This is a two-part fix for #1629:

- Part 1: fix `ctraits.c` to validate the input to `set_default_value` in the case where the given default value type is `DefaultValue.callable_and_args`. This fixes the segfault reported in #1629, replacing it with a more scrutable Python-level exception.
- Part 2: in the `TraitType.clone` base class implementation, when we set a default value, also set the default value type to be consistent with that default value. This still leaves open the possibility for `TraitType` subclasses to do their own thing in their `clone` methods (and in particular, the `List`, `Dict` and `Set` trait types will probably want to take advantage of that - see #1630).

(cherry picked from commit dc59b5c)
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.

None yet

3 participants