Cache: Use explicit arguments for serialize_funct_h5() #448
Conversation
WalkthroughThe pull request introduces significant updates to the handling of function arguments in the Changes
Possibly related PRs
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (4)
- executorlib/cache/shared.py (1 hunks)
- executorlib/interactive/shared.py (1 hunks)
- executorlib/standalone/serialize.py (1 hunks)
- tests/test_cache_shared.py (3 hunks)
🧰 Additional context used
🪛 Ruff
executorlib/standalone/serialize.py
32-32: Do not use mutable data structures for argument defaults
Replace with
None; initialize within function(B006)
32-32: Do not use mutable data structures for argument defaults
Replace with
None; initialize within function(B006)
🔇 Additional comments (7)
executorlib/standalone/serialize.py (1)
31-48: Verify all callers have been updated to use the new signature.The function signature change from variadic arguments to explicit arguments is a breaking change. Let's verify that all callers have been updated accordingly.
✅ Verification successful
Let me try another search strategy to find the callers.
All callers have been updated to use the new signature correctly
The search results show that all callers of
serialize_funct_h5()are already using named arguments with the new signature:
tests/test_cache_shared.py: Uses named argumentsfn=my_funct, fn_args=[...]executorlib/interactive/shared.py: Uses named argumentsfn=task_dict["fn"], fn_args=task_dict["args"], fn_kwargs=task_dict["kwargs"]executorlib/cache/shared.py: Uses named argumentsfn=task_dict["fn"], fn_args=task_args, fn_kwargs=task_kwargsNo instances of variadic argument usage (
*argsor**kwargs) were found. All callers have been properly updated to match the new explicit argument signature.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for all calls to serialize_funct_h5 echo "Searching for function calls..." rg -A 2 "serialize_funct_h5\(" --type python # Look for any remaining *args or **kwargs usage with this function echo "Checking for variadic argument usage..." ast-grep --pattern 'serialize_funct_h5($$$, *$_)' --lang python ast-grep --pattern 'serialize_funct_h5($$$, **$_)' --lang pythonLength of output: 372
Script:
#!/bin/bash # Search for all calls to serialize_funct_h5 using ripgrep with py extension echo "Searching for function calls..." rg -A 2 "serialize_funct_h5\(" --type py # Also search for imports of this function to find potential callers echo "Searching for imports..." rg "from.*serialize.*import.*serialize_funct_h5|import.*serialize.*serialize_funct_h5" --type py # Look at the full serialize.py file to understand the context better echo "Content of serialize.py:" find . -name "serialize.py" -exec cat {} \;Length of output: 4237
🧰 Tools
🪛 Ruff
32-32: Do not use mutable data structures for argument defaults
Replace with
None; initialize within function(B006)
32-32: Do not use mutable data structures for argument defaults
Replace with
None; initialize within function(B006)
tests/test_cache_shared.py (3)
33-35: LGTM! Clear separation of function argumentsThe updated serialize_funct_h5() call with explicit named parameters improves code clarity by clearly distinguishing between positional and keyword arguments.
56-58: LGTM! Consistent with new parameter styleThe updated call maintains clear intent by explicitly showing that only positional arguments are used (empty fn_kwargs).
79-81: LGTM! Maintains consistent argument passing patternThe updated call clearly shows keyword-only argument usage with an empty fn_args list, maintaining consistency with the new parameter style across all test methods.
Let's verify that all calls to serialize_funct_h5 across the codebase follow this new pattern:
✅ Verification successful
All calls to serialize_funct_h5 follow consistent named parameter pattern
The verification shows that all calls to
serialize_funct_h5across the codebase consistently use named parameters:
- Test cases in
tests/test_cache_shared.pyuse explicit named parameters- Production code in
executorlib/interactive/shared.pyandexecutorlib/cache/shared.pyalso uses named parameters- Function definition in
executorlib/standalone/serialize.pydeclares parameters with default values matching the usage pattern🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for any calls to serialize_funct_h5 that might not use named parameters rg "serialize_funct_h5\(" -A 3Length of output: 1658
executorlib/cache/shared.py (2)
97-97: LGTM! Good improvement in code clarity.The transition to named arguments (
fn,fn_args,fn_kwargs) makes the code more explicit and self-documenting. This change reduces the risk of argument order mistakes and improves maintainability.
96-98: Verify consistent argument naming across the codebase.While this change improves clarity, we should ensure consistent argument naming across all calls to
serialize_funct_h5in the codebase.✅ Verification successful
Named arguments are consistently used across the codebase
The verification shows that all calls to
serialize_funct_h5already use named arguments consistently:
- Function definition in
executorlib/standalone/serialize.pydeclares parameters asfn,fn_args, andfn_kwargs- All calls in tests and implementation files use these exact parameter names
- The change in
executorlib/cache/shared.pymaintains this consistency🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for all calls to serialize_funct_h5 to verify consistent argument naming rg -A 2 "serialize_funct_h5\(" --type pythonLength of output: 77
Script:
#!/bin/bash # Search for all calls to serialize_funct_h5 without file type restriction rg -A 2 "serialize_funct_h5\("Length of output: 1274
executorlib/interactive/shared.py (1)
623-623: Ensure allserialize_funct_h5calls use keyword argumentsThe call to
serialize_funct_h5now uses keyword arguments (fn,fn_args,fn_kwargs), which enhances code clarity and reduces the risk of argument misplacement. Please verify that all other calls toserialize_funct_h5across the codebase have been updated to use keyword arguments for consistency.Run the following shell script to identify any calls using positional arguments:
✅ Verification successful
All
serialize_funct_h5calls already use keyword argumentsThe verification shows that all calls to
serialize_funct_h5across the codebase consistently use keyword arguments (fn,fn_args,fn_kwargs). This includes calls in:
tests/test_cache_shared.pyexecutorlib/cache/shared.pyexecutorlib/interactive/shared.py🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Find calls to 'serialize_funct_h5' using positional arguments # Expected result: No matches, confirming consistency ast-grep --pattern 'serialize_funct_h5($_, $_, $_)' --lang pythonLength of output: 1436
executorlib/standalone/serialize.py
Outdated
| binary_all = cloudpickle.dumps({"fn": fn, "args": fn_args, "kwargs": fn_kwargs}) | ||
| task_key = fn.__name__ + _get_hash(binary=binary_all) | ||
| data = {"fn": fn, "args": args, "kwargs": kwargs} | ||
| data = {"fn": fn, "args": fn_args, "kwargs": fn_kwargs} |
There was a problem hiding this comment.
Initialize default arguments within the function body.
After fixing the mutable default arguments, we need to initialize them within the function body.
Apply this change:
+ fn_args = [] if fn_args is None else fn_args
+ fn_kwargs = {} if fn_kwargs is None else fn_kwargs
binary_all = cloudpickle.dumps({"fn": fn, "args": fn_args, "kwargs": fn_kwargs})
task_key = fn.__name__ + _get_hash(binary=binary_all)
data = {"fn": fn, "args": fn_args, "kwargs": fn_kwargs}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| binary_all = cloudpickle.dumps({"fn": fn, "args": fn_args, "kwargs": fn_kwargs}) | |
| task_key = fn.__name__ + _get_hash(binary=binary_all) | |
| data = {"fn": fn, "args": args, "kwargs": kwargs} | |
| data = {"fn": fn, "args": fn_args, "kwargs": fn_kwargs} | |
| fn_args = [] if fn_args is None else fn_args | |
| fn_kwargs = {} if fn_kwargs is None else fn_kwargs | |
| binary_all = cloudpickle.dumps({"fn": fn, "args": fn_args, "kwargs": fn_kwargs}) | |
| task_key = fn.__name__ + _get_hash(binary=binary_all) | |
| data = {"fn": fn, "args": fn_args, "kwargs": fn_kwargs} |
executorlib/standalone/serialize.py
Outdated
| def serialize_funct_h5( | ||
| fn: callable, fn_args: list = [], fn_kwargs: dict = {} | ||
| ) -> Tuple[str, dict]: | ||
| """ | ||
| Serialize a function and its arguments and keyword arguments into an HDF5 file. | ||
|
|
||
| Args: | ||
| fn (callable): The function to be serialized. | ||
| *args (Any): The arguments of the function. | ||
| **kwargs (Any): The keyword arguments of the function. | ||
| fn_args (tuple): The arguments of the function. | ||
| fn_kwargs (dict): The keyword arguments of the function. | ||
|
|
||
| Returns: | ||
| Tuple[str, dict]: A tuple containing the task key and the serialized data. | ||
|
|
There was a problem hiding this comment.
Fix mutable default arguments and docstring accuracy.
- Using mutable objects as default arguments can lead to unexpected behavior when the same default instance is shared across function calls.
- The docstring parameter type for
fn_argsshould belist, nottuple.
Apply these changes:
def serialize_funct_h5(
- fn: callable, fn_args: list = [], fn_kwargs: dict = {}
+ fn: callable, fn_args: list | None = None, fn_kwargs: dict | None = None
) -> Tuple[str, dict]:
"""
Serialize a function and its arguments and keyword arguments into an HDF5 file.
Args:
fn (callable): The function to be serialized.
- fn_args (tuple): The arguments of the function.
+ fn_args (list): The arguments of the function.
fn_kwargs (dict): The keyword arguments of the function.
Returns:
Tuple[str, dict]: A tuple containing the task key and the serialized data.
"""📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| def serialize_funct_h5( | |
| fn: callable, fn_args: list = [], fn_kwargs: dict = {} | |
| ) -> Tuple[str, dict]: | |
| """ | |
| Serialize a function and its arguments and keyword arguments into an HDF5 file. | |
| Args: | |
| fn (callable): The function to be serialized. | |
| *args (Any): The arguments of the function. | |
| **kwargs (Any): The keyword arguments of the function. | |
| fn_args (tuple): The arguments of the function. | |
| fn_kwargs (dict): The keyword arguments of the function. | |
| Returns: | |
| Tuple[str, dict]: A tuple containing the task key and the serialized data. | |
| def serialize_funct_h5( | |
| fn: callable, fn_args: list | None = None, fn_kwargs: dict | None = None | |
| ) -> Tuple[str, dict]: | |
| """ | |
| Serialize a function and its arguments and keyword arguments into an HDF5 file. | |
| Args: | |
| fn (callable): The function to be serialized. | |
| fn_args (list): The arguments of the function. | |
| fn_kwargs (dict): The keyword arguments of the function. | |
| Returns: | |
| Tuple[str, dict]: A tuple containing the task key and the serialized data. | |
| """ |
🧰 Tools
🪛 Ruff
32-32: Do not use mutable data structures for argument defaults
Replace with
None; initialize within function(B006)
32-32: Do not use mutable data structures for argument defaults
Replace with
None; initialize within function(B006)
…ze_funct_h5 # Conflicts: # executorlib/standalone/serialize.py
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
tests/test_cache_executor_serial.py (1)
58-66: LGTM! Consider documenting the resource_dict parameter.The addition of
resource_dictaligns with the PR's objective. While the empty dictionary is a reasonable default for tests, consider adding a brief comment explaining its purpose for future maintainers.q.put( { "fn": my_funct, "args": (), "kwargs": {"a": 1, "b": 2}, "future": fs1, + # Empty resource_dict as no special execution resources are needed for this test "resource_dict": {}, } )
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (6)
- executorlib/base/executor.py (2 hunks)
- executorlib/cache/shared.py (1 hunks)
- executorlib/interactive/shared.py (3 hunks)
- executorlib/standalone/serialize.py (1 hunks)
- tests/test_cache_executor_serial.py (3 hunks)
- tests/test_cache_shared.py (3 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- executorlib/cache/shared.py
- tests/test_cache_shared.py
🧰 Additional context used
🪛 Ruff
executorlib/interactive/shared.py
25-25: Do not use mutable data structures for argument defaults
Replace with
None; initialize within function(B006)
executorlib/standalone/serialize.py
32-32: Do not use mutable data structures for argument defaults
Replace with
None; initialize within function(B006)
32-32: Do not use mutable data structures for argument defaults
Replace with
None; initialize within function(B006)
32-32: Do not use mutable data structures for argument defaults
Replace with
None; initialize within function(B006)
🔇 Additional comments (10)
executorlib/standalone/serialize.py (3)
31-33: Previous review comment about mutable defaults is still applicable.The issue with mutable default arguments needs to be addressed as suggested in the previous review.
🧰 Tools
🪛 Ruff
32-32: Do not use mutable data structures for argument defaults
Replace with
None; initialize within function(B006)
32-32: Do not use mutable data structures for argument defaults
Replace with
None; initialize within function(B006)
32-32: Do not use mutable data structures for argument defaults
Replace with
None; initialize within function(B006)
39-50: LGTM! Well-documented parameters with clear examples.The docstring provides comprehensive documentation, especially for the new
resource_dictparameter with its detailed example structure.
56-65:⚠️ Potential issueInitialize default arguments within function body.
The function should initialize default arguments at the start of the function body to avoid mutable default argument issues.
Apply this change:
def serialize_funct_h5( - fn: callable, fn_args: list = [], fn_kwargs: dict = {}, resource_dict: dict = {} + fn: callable, fn_args: list | None = None, fn_kwargs: dict | None = None, resource_dict: dict | None = None ) -> Tuple[str, dict]: + fn_args = [] if fn_args is None else fn_args + fn_kwargs = {} if fn_kwargs is None else fn_kwargs + resource_dict = {} if resource_dict is None else resource_dict binary_all = cloudpickle.dumps( {"fn": fn, "args": fn_args, "kwargs": fn_kwargs, "resource_dict": resource_dict} )Additionally, let's verify the impact of these changes:
✅ Verification successful
Let me analyze the usage of
serialize_funct_h5further to ensure we understand the full impact of the changes.
Based on the gathered information, I can now generate the final response:
Initialize default arguments within function body to prevent mutable default argument issues
The suggested changes to initialize default arguments within the function body are correct and safe to implement because:
- All test cases explicitly provide their arguments rather than relying on defaults
- The serialization and deserialization process (via cloudpickle) operates on the actual values, not the default arguments
- The function is used in multiple places (
executorlib/interactive/shared.py,executorlib/cache/shared.py) but always with explicit argumentsApply the suggested changes:
def serialize_funct_h5( - fn: callable, fn_args: list = [], fn_kwargs: dict = {}, resource_dict: dict = {} + fn: callable, fn_args: list | None = None, fn_kwargs: dict | None = None, resource_dict: dict | None = None ) -> Tuple[str, dict]: + fn_args = [] if fn_args is None else fn_args + fn_kwargs = {} if fn_kwargs is None else fn_kwargs + resource_dict = {} if resource_dict is None else resource_dict🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any existing serialized data that might be affected by the changes # Look for potential HDF5 files or serialized data echo "Searching for HDF5 files and serialized data..." fd -e h5 -e hdf5 # Check for other uses of serialize_funct_h5 echo "Checking for other uses of serialize_funct_h5..." rg "serialize_funct_h5" -A 3Length of output: 2529
Script:
#!/bin/bash # Check the test cases to understand how the function behaves with default arguments rg -B 5 -A 10 "serialize_funct_h5\(" tests/ # Look for any deserialization code that might be affected rg "cloudpickle\.loads"Length of output: 4997
executorlib/base/executor.py (2)
10-10: LGTM: Import changes align with code modificationsThe import changes correctly reflect the transition from using
check_resource_dict_is_emptytocheck_resource_dict.
91-99: Verify resource dictionary validation and handlingWhile the code changes simplify the submission process, there are several concerns to address:
- The removal of the empty resource dictionary check might affect existing code that relied on this validation
- There's no explicit validation of the resource dictionary structure before queueing
- Resource management implications should be carefully considered
Let's verify the impact and usage patterns:
Consider implementing the following safeguards:
- Add validation of resource dictionary structure before queueing
- Consider adding logging for resource allocation tracking
- Document the expected resource dictionary structure in the method docstring
✅ Verification successful
Let me run another script to better understand the validation and usage patterns:
Resource dictionary validation is correctly maintained
The code changes are safe because:
- The
check_resource_dict()validation is still called before queueing (line shown in executor.py), which ensures the function doesn't use reserved parameter names- The removal of empty resource dict check is intentional as the code now supports resource dictionaries with valid resource requirements (as documented in the submit method's docstring)
- The resource dictionary structure is well-defined in the documentation, specifying expected fields like cores, threads_per_core, gpus_per_worker, etc.
- Test coverage exists for resource dictionary validation in test_shared_input_check.py
The changes align with the codebase's resource management design and maintain proper validation where needed.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for existing usage patterns of resource dictionaries # and potential validation points # Look for resource dictionary usage patterns echo "Checking resource dictionary usage patterns..." rg -A 3 "resource_dict.*=.*{}" # Look for any existing validation of resource dictionaries echo "Checking resource dictionary validation patterns..." rg -A 3 "check_resource_dict" # Look for tests involving resource dictionaries echo "Checking test coverage for resource dictionaries..." fd -e py -x rg -l "resource_dict" {} tests/Length of output: 12198
Script:
#!/bin/bash # Check the implementation of resource dict validation echo "Checking resource dict validation implementation:" rg -A 10 "def check_resource_dict" executorlib/ # Check for resource dict usage in executor echo -e "\nChecking resource dict usage in executor:" rg -A 10 "resource_dict" executorlib/base/executor.py # Check test cases for resource dict echo -e "\nChecking test cases for resource dict:" rg -A 5 "resource_dict" tests/test_shared_input_check.pyLength of output: 4875
tests/test_cache_executor_serial.py (2)
91-108: LGTM! Consistent implementation of resource_dict.The addition of
resource_dictis consistent across both task dictionaries, maintaining proper test structure while testing keyword argument dependencies.
133-150: LGTM! Verify resource_dict handling in the executor implementation.The changes maintain consistency across all test cases. Let's verify that the executor implementation properly handles the resource_dict parameter.
✅ Verification successful
Let me generate another script to check the executor implementation since the previous
rgcommand failed:
Based on the results, I can now generate the final response:
Verified: resource_dict is properly handled in executor implementations
The resource_dict parameter is consistently implemented across the codebase:
- Properly validated through
check_resource_dictin executor submission- Correctly passed through task queues in both cache and dependency executors
- Consistently structured in test cases with both empty {} and specific resource requirements (e.g., {"cores": 1})
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that resource_dict is properly handled in the executor implementation # Test: Check if execute_tasks_h5 and related functions handle resource_dict rg -A 5 "resource_dict" --type python # Test: Check if the task dictionary structure is consistent across the codebase ast-grep --pattern 'q.put({ $$$ "resource_dict": $_, $$$ })'Length of output: 4263
Script:
#!/bin/bash # Search for executor implementation files and check resource_dict handling fd executor --type f --exec rg -A 5 "resource_dict" {} # Also check task execution related functions rg -A 5 "execute_tasks" --type-add 'python:*.py' --type pythonLength of output: 10164
executorlib/interactive/shared.py (3)
11-14: LGTM: Clean import organizationThe new imports for resource dictionary validation functions are well-organized and properly grouped.
26-54: LGTM: Well-implemented submit methodThe implementation includes:
- Comprehensive docstring with clear examples
- Proper resource dictionary validation
- Appropriate Future handling
619-622: LGTM: Improved clarity with named argumentsThe update to use named arguments in
serialize_funct_h5call enhances code readability by making the parameter roles explicit.
| @@ -19,6 +22,37 @@ | |||
|
|
|||
|
|
|||
| class ExecutorBroker(ExecutorBase): | |||
| def submit(self, fn: callable, *args, resource_dict: dict = {}, **kwargs) -> Future: | |||
There was a problem hiding this comment.
Replace mutable default argument
Using a mutable default argument (empty dict) can lead to unexpected behavior when the default value is shared between function calls.
Apply this fix:
- def submit(self, fn: callable, *args, resource_dict: dict = {}, **kwargs) -> Future:
+ def submit(self, fn: callable, *args, resource_dict: dict | None = None, **kwargs) -> Future:And add this check at the beginning of the method:
if resource_dict is None:
resource_dict = {}🧰 Tools
🪛 Ruff
25-25: Do not use mutable data structures for argument defaults
Replace with
None; initialize within function(B006)
# Conflicts: # executorlib/interactive/shared.py
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (2)
executorlib/interactive/shared.py (1)
25-25: Add return type annotation to method signatureThe method signature should include the return type annotation for better type safety and documentation.
- def submit(self, fn: callable, *args, resource_dict: dict = {}, **kwargs) -> Future: + def submit(self, fn: callable, *args, resource_dict: dict = {}, **kwargs) -> "concurrent.futures.Future":🧰 Tools
🪛 Ruff
25-25: Do not use mutable data structures for argument defaults
Replace with
None; initialize within function(B006)
executorlib/interactive/executor.py (1)
40-41: Update Docstring to Reflect Base Class ChangeThe docstring should accurately reflect the inheritance from
ExecutorBase. Consider updating it to mention any changes in behavior or differences from the previous base class.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
- executorlib/base/executor.py (2 hunks)
- executorlib/interactive/executor.py (2 hunks)
- executorlib/interactive/shared.py (4 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- executorlib/base/executor.py
🧰 Additional context used
🪛 Ruff
executorlib/interactive/shared.py
25-25: Do not use mutable data structures for argument defaults
Replace with
None; initialize within function(B006)
🔇 Additional comments (3)
executorlib/interactive/shared.py (1)
593-596: LGTM! Improved clarity with named argumentsThe transition from positional to named arguments in the
serialize_funct_h5call enhances code readability and maintainability.executorlib/interactive/executor.py (2)
4-4: EnsureExecutorBaseProvides Required FunctionalityThe import now brings in
ExecutorBasefromexecutorlib.base.executor. Verify thatExecutorBaseoffers all the necessary methods and properties that were previously provided byExecutorSteps.
38-41: Verify Impact of Changing Base Class toExecutorBaseThe
ExecutorWithDependenciesclass now inherits fromExecutorBaseinstead ofExecutorSteps. Ensure this change doesn't omit any essential functionality and that all inherited methods behave as expected.
| @@ -151,7 +145,7 @@ def __init__( | |||
| ) | |||
|
|
|||
|
|
|||
| class InteractiveStepExecutor(ExecutorSteps): | |||
| class InteractiveStepExecutor(ExecutorBase): | |||
There was a problem hiding this comment.
Fix incorrect class name in docstring example
The example in the docstring uses PyFluxStepExecutor, but the actual class name is InteractiveStepExecutor.
Update the example in the docstring:
->>> with PyFluxStepExecutor(max_cores=2) as p:
+>>> with InteractiveStepExecutor(max_cores=2) as p:Committable suggestion was skipped due to low confidence.
Summary by CodeRabbit
New Features
submitmethod in theExecutorBrokerclass.resource_dictto task submissions, enhancing data structure for processing.ExecutorWithDependenciesclass to extendExecutorBase, improving its structure.Bug Fixes
Tests
serialize_funct_h5function, improving clarity in test logic.resource_dictinto test payloads for consistency in data processing.