Repository navigation
Fix lambda defaults for callable Protocol types not resolving to class_path and init_args - #1034
Conversation
…s_path and init_args
[Medium impact] The changes affect the shared path that resolves annotated factory defaults. Guard callable protocol lambda conversion before merging so it cannot silently change factory results. Findings
SummaryThe PR resolves lambda defaults for callable protocols and fixes argument counting for optional callables.
Reviews (1) · Last reviewed commit: "Fix lambda defaults for callable Protoco..." · Reviewed by Greptile |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1034 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 27 27
Lines 10091 10095 +4
=========================================
+ Hits 10091 10095 +4 ☔ View full report in Codecov by Harness. |
|



What does this PR do?
Follow-up to #1033. A default like
lambda p: Impl(p, lr=0.5)was resolved to aclass_pathwithinit_argsonly when the parameter's type wasCallable[...]. With the equivalent callableProtocol(alsoOptional[...]), the lambda was kept as is, so dumping the config showedUnable to serialize instanceand overriding e.g.--step.init_args.lrfailed.Changes:
Callableor callableProtocol, that returns a class.__call__signature, andOptionalis stripped first. Before, anOptional[Callable]with more than one parameter was miscounted, so a default likelambda p, lr: Impl(p, lr)was not resolved.Callable, callableProtocolandOptionalcallableProtocol, plus anOptional[Callable]with two positional arguments.lambda p: Impl(p[::-1], lr=0.5), which before was resolved and silently lost the[::-1].Before submitting