PortNamespace: do not set dynamic=False when valid_type=None
#146
Conversation
sphuber
force-pushed
the
fix_135_expose_keep_dynamic_attribute
branch
from
1d054f1 to
5b7471d
Compare
|
Agree with the change, but I'm not sure should close #146 just yet. As you mentioned elsewhere, the whole automatic setting of |
|
Sorry, shouldn't close #135 yet. |
And in AiiDA I guess it can go into 1.2.0, since it is a breaking change, but only a minor one. We don't do strict semver, right? |
We don't do strict as in no breaking changes whatsoever, zero, zilch, since that is almost impossible, but since But couldn't we just follow the same logic and just put this in And why shouldn't this close #135? Is this because the more refined question that you brought up later regarding precedence of |
|
Well, As for #135, a separate issue might indeed be cleaner. |
|
I will merge this and release it with |
sphuber
force-pushed
the
fix_135_expose_keep_dynamic_attribute
branch
from
777ee43 to
8141488
Compare
When setting `valid_type` to anything but `None` the setter will automatically also set `dynamic` to `True`, because this almost always what one wants and so saves having to set this attribute explicitly. Setting a valid type for a namespace but then not allowing any value whatsoever is non-sensical. The `valid_type` setter also implemented the reverse, meaning that setting `valid_type=None` would automatically set `dynamic=False`. This use case is a lot less common and actually leads to a lot of problems since the default `valid_type` of a namespace is `None`. When exposing a namespace that is dynamic, but without a particular `valid_type`, which is perfectly fine logically - it just accepts any value, the exposed namespace would lose its dynamicity. This is because the `valid_type` would be set after the `dynamic`, resetting it to `False` because the `valid_type` is `None`.
sphuber
force-pushed
the
fix_135_expose_keep_dynamic_attribute
branch
from
8141488 to
2a66b31
Compare
…iidateam#146) When setting `valid_type` to anything but `None` the setter will automatically also set `dynamic` to `True`, because this almost always what one wants and so saves having to set this attribute explicitly. Setting a valid type for a namespace but then not allowing any value whatsoever is non-sensical. The `valid_type` setter also implemented the reverse, meaning that setting `valid_type=None` would automatically set `dynamic=False`. This use case is a lot less common and actually leads to a lot of problems since the default `valid_type` of a namespace is `None`. When exposing a namespace that is dynamic, but without a particular `valid_type`, which is perfectly fine logically - it just accepts any value, the exposed namespace would lose its dynamicity. This is because the `valid_type` would be set after the `dynamic`, resetting it to `False` because the `valid_type` is `None`.
Fixes #135
When setting
valid_typeto anything butNonethe setter willautomatically also set
dynamictoTrue, because this almost alwayswhat one wants and so saves having to set this attribute explicitly.
Setting a valid type for a namespace but then not allowing any value
whatsoever is non-sensical.
The
valid_typesetter also implemented the reverse, meaning thatsetting
valid_type=Nonewould automatically setdynamic=False. Thisuse case is a lot less common and actually leads to a lot of problems
since the default
valid_typeof a namespace isNone. When exposing anamespace that is dynamic, but without a particular
valid_type, whichis perfectly fine logically - it just accepts any value, the exposed
namespace would lose its dynamicity. This is because the
valid_typewould be set after the
dynamic, resetting it toFalsebecause thevalid_typeisNone.