-
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
Add 'factory' support for the Any trait type #1557
Conversation
Looking into the stubs-related test failure ... |
I think the mypy complaint is legitimate here. I've updated the test accordingly. |
Whoops; the user manual does need updating here. Now done. |
@@ -278,7 +278,9 @@ the table. | |||
+------------------+----------------------------------------------------------+ | |||
| Name | Callable Signature | | |||
+==================+==========================================================+ | |||
| Any | Any( [*value* = None, \*\*\ *metadata*] ) | |
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.
Corrected the name of the initial parameter from value
to default_value
(though I expect few people will be passing that parameter by name).
|
||
|
||
class Subclass(Superclass): | ||
x = Instance(Foo) | ||
x = Instance(Foo) # E: assignment |
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 line didn't raise before this PR, and does now; I believe that this was a bug in the test. mypy
infers from Superclass
that the attribute x
should have type Any
, and complains about the non-matching assignment in the subclass, which seems like a legitimate complaint.
*, | ||
factory=None, | ||
args=(), | ||
kw={}, |
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, this is considered an antipattern (compared to using kw=None
and then explicitly checking for None
in the body of the function). No, I don't want to change it unless people feel really strongly about it. A default of {}
makes the code, documentation and typing stubs simpler and clearer, and the usual concern about mutable default values doesn't apply here, because there's no plausible way that accidental mutation of this default value could take place.
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.
LGTM with one small comment about documentation
Co-authored-by: Poruri Sai Rahul <rporuri@enthought.com>
This PR adds
factory
,args
andkw
keyword-only arguments to theAny
trait type initializer, allowing a default value for anAny
trait to be specified via a factory, in much the same way as this already works for theInstance
trait type.The main goal is to provide a clean migration path for existing code using
Any({})
orAny([])
. With Traits 6.3, such code will run into the deprecation introduced in #1532, and can now useAny(factory=dict)
orAny(factory=list)
as a suitable replacement that won't warn.Checklist
docs/source/traits_api_reference
)docs/source/traits_user_manual
)traits-stubs