-
Notifications
You must be signed in to change notification settings - Fork 85
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
Conversation
There was a problem hiding this 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; |
There was a problem hiding this comment.
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 so we can do NULL
herereturn PyErr_Format(...)
. Right? Or is the convention not to do so?
Ref https://docs.python.org/3/c-api/exceptions.html#c.PyErr_Format
There was a problem hiding this comment.
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
.
…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)
This is a two-part fix for #1629:
ctraits.c
to validate the input toset_default_value
in the case where the given default value type isDefaultValue.callable_and_args
. This fixes the segfault reported in ClonedTraitTypes
don't properly account forcallable_and_args
defaults #1629, replacing it with a more scrutable Python-level exception.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 forTraitType
subclasses to do their own thing in theirclone
methods (and in particular, theList
,Dict
andSet
trait types will probably want to take advantage of that - see Trait inheritance doesn't work as expected for List traits #1630).Checklist
docs/source/traits_api_reference
) N/Adocs/source/traits_user_manual
) N/Atraits-stubs
N/A