-
-
Notifications
You must be signed in to change notification settings - Fork 200
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
how to extend dynamic defaults with super #256
Comments
The 4.0 syntax is still valid (albeit with If methods named Outside of that option though, we could define a public method *note: I can see a potential use case for a metaclass setup step in which |
To add to this question though: There is no easy way to apply modifications to the value of This could potentially be answered in #230 or #251 by passing a bunch to default generators (checking the function signature before doing so to keep things backward compatible) |
No, I mean there's no way to answer the question "what would the dynamic default value have been in my parent class," which is used often in subclasses to modify defaults. Let's say I have the following: class Parent(HasTraits):
some_trait = List(Unicode())
def _some_trait_default(self):
return [ os.getcwd() ] In 4.0 and earlier, I could reliably extend this class to add to the default in the child: class Child(Parent):
def _some_trait_default(self):
return super(). _some_trait_default() + ['/'] As far as I can tell, this pattern is now impossible via public APIs, because I can no longer determine what the |
So you saying that because there's not a naming scheme for default generators you can have a situation like this: class Parent(HasTraits):
i = Int()
@default('i')
def _dgen1(self):
return 1
class Subclass(Parent):
@default('i')
def _dgen2(self):
# raises attribute error
return super(Subclass)._dgen2() + 1 Where super is only reliable when new default generators override the parent method instead of defining new ones. |
The main problem is that the name of |
I thought about this again today, and while you can reliably call class A(HasTraits):
i = Int()
def _i_default(self):
return 1
class B(A):
i = Int(2)
b = B()
true_default = b.i
false_default = b._i_default()
print(true_default)
print(false_default) As it turns out, |
@minrk what's you're take on the above issue? IMO this is an insoluble problem given our current heuristics. |
Good point, though in practice it worked. We've never had a true, public mechanism for asking the 'what would my default have been'. It would be nice to come up with one. |
I've been working on some unobtrusive changes that would make it possible to introspect HasTraits._trait_default_generators[trait](instance) Likewise, |
With traitlets 4.0, it's easy to extend dynamic defaults of parent classes, because the name of the default generator is part of the public API:
Now that the name of the method that happens to implement the default generator is no longer a public API, what's the best way to determine what the dynamic default would have been in the parent class, and then extend it in a subclass?
The text was updated successfully, but these errors were encountered: