Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix process decorators and make them more flexible
What does this add?
This PR completely refactors/reworks the decorator methodology introduced in #488 into something that fully completes the proposed API
Who is it for?
Closes #923
Why is it needed?
The decorators that were introduced did not work as intended, and only worked to have the
Accelerator
object itself actually use it. To use it outside theAccelerator
was impossible. As a result, this PR completely reworks how the existing decorators were designed by making them utilize thestate
instead, and ensures that a special internal use case is added when using the decorators back on theAccelerator
class itself, with a raised error if a user tries to do the same.What parts of the API does this impact?
User-facing:
A user can now actually perform
@accelerator.on_main_process
as a decorator, along with the rest of the existing ones.The
AcceleratorState
also now stores theuse_distributed
value originally in theAccelerator
objectInternal structure:
The existing implementation in
Accelerator
was gutted, and reworked into a usable fashion.Specifically, this logic has now been added to the decorators:
This check is to ensure if
self
is a function from theAccelerator
itself, or the behavior that occurs when performing:Instead of requiring complex workarounds. As you can see in the above, a proper error will also be raised if a user breaks this "magic" with a clear description of what is happening.
Inside the
on_process*
functions there also exists this snippet:This is to check if an overloaded decorator was used, potentially again on the
Accelerator
class, before moving on to the proper constructor.Basic Usage Example(s):