-
Notifications
You must be signed in to change notification settings - Fork 587
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
Remove the umbrella import. #1
Closed
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ZacharyGarrett
approved these changes
Dec 19, 2018
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.
Approving to test the workflow.
copybara-service bot
pushed a commit
that referenced
this pull request
Jan 18, 2023
This revealed two Python typing-related issues: 1. Every subclass of `executor_base.Executor` was using a property on the corresponding subclass of `executor_value_base.ExecutorValue` without having access to that property. This was fixed by: 2. The methods on the subclasses of `federating_executor.FederatingStrategy` (`FederatedComposingStrategy` and `FederatedResolvingStrategy`) were annotated to return types specific to that subclass. This return type conflicted with the return types of the shared implementations defined in `executor_utils`. 3. The type annotation of `target_executors` parameter of `FederatedResolvingStrategy` was incorrect. * Enabled pytype in the following modules: * `federated_composing_strategy` * `federated_resolving_strategy` * `federating_executor` * `reference_resolving_executor` * `remote_executor` * `thread_delegating_executor` * `value_serialization` To fix issue #1: * Promoted the `reference` property from the subclasses of `executor_value_base.ExecutorValue` to `executor_value_base.ExecutorValue`. * Renamed usage of this API to be consistent. To fix issue #2: * Updated the methods on the subclasses of `federating_executor.FederatingStrategy` (`FederatedComposingStrategy` and `FederatedResolvingStrategy`) to accept and return `executor_value_base.ExecutorValue` types. Note: That this does make the return types more generic, but I believe this is the intended interface. An alternative fix could be to update the `executor_utils` function to take and return `TypeVar`'s (i.e. generic functions). However, I don't think this is the intended interface. To fix issue #3: * Updated the type annotation of the `target_executors` parameter to `dict[placements.PlacementLiteral, Union[list[executor_base.Executor], executor_base.Executor]]`. PiperOrigin-RevId: 502890245
copybara-service bot
pushed a commit
that referenced
this pull request
Jan 23, 2023
…cutors` package. This revealed two Python typing-related issues: 1. Every subclass of `executor_base.Executor` was using a property on the corresponding subclass of `executor_value_base.ExecutorValue` without having access to that property. This was fixed by: 2. The methods on the subclasses of `federating_executor.FederatingStrategy` (`FederatedComposingStrategy` and `FederatedResolvingStrategy`) were annotated to return types specific to that subclass. This return type conflicted with the return types of the shared implementations defined in `executor_utils`. 3. The type annotation of `target_executors` parameter of `FederatedResolvingStrategy` was incorrect. * Enabled pytype in the following modules: * `federated_composing_strategy` * `federated_resolving_strategy` * `federating_executor` * `reference_resolving_executor` * `remote_executor` * `thread_delegating_executor` * `value_serialization` To fix issue #1: * Promoted the `reference` property from the subclasses of `executor_value_base.ExecutorValue` to `executor_value_base.ExecutorValue`. * Renamed usage of this API to be consistent. To fix issue #2: * Updated the methods on the subclasses of `federating_executor.FederatingStrategy` (`FederatedComposingStrategy` and `FederatedResolvingStrategy`) to accept and return `executor_value_base.ExecutorValue` types. Note: That this does make the return types more generic, but I believe this is the intended interface. An alternative fix could be to update the `executor_utils` function to take and return `TypeVar`'s (i.e. generic functions). However, I don't think this is the intended interface. To fix issue #3: * Updated the type annotation of the `target_executors` parameter to `dict[placements.PlacementLiteral, Union[list[executor_base.Executor], executor_base.Executor]]`. PiperOrigin-RevId: 502890245
copybara-service bot
pushed a commit
that referenced
this pull request
Jan 23, 2023
…cutors` package. This revealed two Python typing-related issues: 1. Every subclass of `executor_base.Executor` was using a property on the corresponding subclass of `executor_value_base.ExecutorValue` without having access to that property. This was fixed by: 2. The methods on the subclasses of `federating_executor.FederatingStrategy` (`FederatedComposingStrategy` and `FederatedResolvingStrategy`) were annotated to return types specific to that subclass. This return type conflicted with the return types of the shared implementations defined in `executor_utils`. 3. The type annotation of `target_executors` parameter of `FederatedResolvingStrategy` was incorrect. * Enabled pytype in the following modules: * `federated_composing_strategy` * `federated_resolving_strategy` * `federating_executor` * `reference_resolving_executor` * `remote_executor` * `thread_delegating_executor` * `value_serialization` To fix issue #1: * Promoted the `reference` property from the subclasses of `executor_value_base.ExecutorValue` to `executor_value_base.ExecutorValue`. * Renamed usage of this API to be consistent. To fix issue #2: * Updated the methods on the subclasses of `federating_executor.FederatingStrategy` (`FederatedComposingStrategy` and `FederatedResolvingStrategy`) to accept and return `executor_value_base.ExecutorValue` types. Note: That this does make the return types more generic, but I believe this is the intended interface. An alternative fix could be to update the `executor_utils` function to take and return `TypeVar`'s (i.e. generic functions). However, I don't think this is the intended interface. To fix issue #3: * Updated the type annotation of the `target_executors` parameter to `dict[placements.PlacementLiteral, Union[list[executor_base.Executor], executor_base.Executor]]`. PiperOrigin-RevId: 502890245
copybara-service bot
pushed a commit
that referenced
this pull request
Jan 23, 2023
…cutors` package. This revealed two Python typing-related issues: 1. Every subclass of `executor_base.Executor` was using a property on the corresponding subclass of `executor_value_base.ExecutorValue` without having access to that property. This was fixed by: 2. The methods on the subclasses of `federating_executor.FederatingStrategy` (`FederatedComposingStrategy` and `FederatedResolvingStrategy`) were annotated to return types specific to that subclass. This return type conflicted with the return types of the shared implementations defined in `executor_utils`. 3. The type annotation of `target_executors` parameter of `FederatedResolvingStrategy` was incorrect. * Enabled pytype in the following modules: * `federated_composing_strategy` * `federated_resolving_strategy` * `federating_executor` * `reference_resolving_executor` * `remote_executor` * `thread_delegating_executor` * `value_serialization` To fix issue #1: * Promoted the `reference` property from the subclasses of `executor_value_base.ExecutorValue` to `executor_value_base.ExecutorValue`. * Renamed usage of this API to be consistent. To fix issue #2: * Updated the methods on the subclasses of `federating_executor.FederatingStrategy` (`FederatedComposingStrategy` and `FederatedResolvingStrategy`) to accept and return `executor_value_base.ExecutorValue` types. Note: That this does make the return types more generic, but I believe this is the intended interface. An alternative fix could be to update the `executor_utils` function to take and return `TypeVar`'s (i.e. generic functions). However, I don't think this is the intended interface. To fix issue #3: * Updated the type annotation of the `target_executors` parameter to `dict[placements.PlacementLiteral, Union[list[executor_base.Executor], executor_base.Executor]]`. PiperOrigin-RevId: 502890245
copybara-service bot
pushed a commit
that referenced
this pull request
Jan 24, 2023
…cutors` package. This revealed two Python typing-related issues: 1. Every subclass of `executor_base.Executor` was using a property on the corresponding subclass of `executor_value_base.ExecutorValue` without having access to that property. This was fixed by: 2. The methods on the subclasses of `federating_executor.FederatingStrategy` (`FederatedComposingStrategy` and `FederatedResolvingStrategy`) were annotated to return types specific to that subclass. This return type conflicted with the return types of the shared implementations defined in `executor_utils`. 3. The type annotation of `target_executors` parameter of `FederatedResolvingStrategy` was incorrect. * Enabled pytype in the following modules: * `federated_composing_strategy` * `federated_resolving_strategy` * `federating_executor` * `reference_resolving_executor` * `remote_executor` * `thread_delegating_executor` * `value_serialization` To fix issue #1: * Promoted the `reference` property from the subclasses of `executor_value_base.ExecutorValue` to `executor_value_base.ExecutorValue`. * Renamed usage of this API to be consistent. To fix issue #2: * Updated the methods on the subclasses of `federating_executor.FederatingStrategy` (`FederatedComposingStrategy` and `FederatedResolvingStrategy`) to accept and return `executor_value_base.ExecutorValue` types. Note: That this does make the return types more generic, but I believe this is the intended interface. An alternative fix could be to update the `executor_utils` function to take and return `TypeVar`'s (i.e. generic functions). However, I don't think this is the intended interface. To fix issue #3: * Updated the type annotation of the `target_executors` parameter to `dict[placements.PlacementLiteral, Union[list[executor_base.Executor], executor_base.Executor]]`. PiperOrigin-RevId: 502890245
copybara-service bot
pushed a commit
that referenced
this pull request
Jan 24, 2023
…cutors` package. This revealed two Python typing-related issues: 1. Every subclass of `executor_base.Executor` was using a property on the corresponding subclass of `executor_value_base.ExecutorValue` without having access to that property. This was fixed by: 2. The methods on the subclasses of `federating_executor.FederatingStrategy` (`FederatedComposingStrategy` and `FederatedResolvingStrategy`) were annotated to return types specific to that subclass. This return type conflicted with the return types of the shared implementations defined in `executor_utils`. 3. The type annotation of `target_executors` parameter of `FederatedResolvingStrategy` was incorrect. * Enabled pytype in the following modules: * `federated_composing_strategy` * `federated_resolving_strategy` * `federating_executor` * `reference_resolving_executor` * `remote_executor` * `thread_delegating_executor` * `value_serialization` To fix issue #1: * Promoted the `reference` property from the subclasses of `executor_value_base.ExecutorValue` to `executor_value_base.ExecutorValue`. * Renamed usage of this API to be consistent. To fix issue #2: * Updated the methods on the subclasses of `federating_executor.FederatingStrategy` (`FederatedComposingStrategy` and `FederatedResolvingStrategy`) to accept and return `executor_value_base.ExecutorValue` types. Note: That this does make the return types more generic, but I believe this is the intended interface. An alternative fix could be to update the `executor_utils` function to take and return `TypeVar`'s (i.e. generic functions). However, I don't think this is the intended interface. To fix issue #3: * Updated the type annotation of the `target_executors` parameter to `dict[placements.PlacementLiteral, Union[list[executor_base.Executor], executor_base.Executor]]`. PiperOrigin-RevId: 504114859
copybara-service bot
pushed a commit
that referenced
this pull request
Sep 25, 2023
1. Rollback cl/348558130 - Refactors the computation wrapper to allow for non-tracing strategies. 2. Rollback cl/334208326 - Remove the remaining TFF stack frames from tracing errors. 4. Rollback cl/333598731 - Invert control of some tracing functions to shorten stacktraces. PiperOrigin-RevId: 568323122
copybara-service bot
pushed a commit
that referenced
this pull request
Sep 27, 2023
These three CLs are stacked on top of each other and they make the tracing logic more complex. Rolling these CLs back will simplify tracing logic and improve static analysis and lint. The stacktraces will have more depth, but hopefully they will also be more clear as well. 1. Revert b82dd1a - Refactors the computation wrapper to allow for non-tracing strategies. 2. Revert 827f21e - Remove the remaining TFF stack frames from tracing errors. 4. Revert 1406a91 - Invert control of some tracing functions to shorten stacktraces. PiperOrigin-RevId: 568323122
copybara-service bot
pushed a commit
that referenced
this pull request
Sep 27, 2023
These three CLs are stacked on top of each other and they make the tracing logic more complex. Rolling these CLs back will simplify tracing logic and improve static analysis and lint. The stacktraces will have more depth, but hopefully they will also be more clear as well. 1. Revert b82dd1a - Refactors the computation wrapper to allow for non-tracing strategies. 2. Revert 827f21e - Remove the remaining TFF stack frames from tracing errors. 4. Revert 1406a91 - Invert control of some tracing functions to shorten stacktraces. PiperOrigin-RevId: 568323122
copybara-service bot
pushed a commit
that referenced
this pull request
Sep 27, 2023
These three CLs are stacked on top of each other and they make the tracing logic more complex. Rolling these CLs back will simplify tracing logic and improve static analysis and lint. The stacktraces will have more depth, but hopefully they will also be more clear as well. 1. Revert b82dd1a - Refactors the computation wrapper to allow for non-tracing strategies. 2. Revert 827f21e - Remove the remaining TFF stack frames from tracing errors. 4. Revert 1406a91 - Invert control of some tracing functions to shorten stacktraces. PiperOrigin-RevId: 568323122
copybara-service bot
pushed a commit
that referenced
this pull request
Sep 17, 2024
``` # expansion is pretty cool # https://www.gnu.org/software/bash/manual/html_node/Shell-Expansions.html echo "hello `world`" echo "hello ${world}" # single quotes disable expansion # https://www.gnu.org/software/bash/manual/html_node/Single-Quotes.html echo 'hello `world`' echo 'hello ${world}' # Problem - single quotes in single quotes echo 'hello ' world' # Fix #1: quote the single quote, which is exciting echo 'hello '"'"' world' # Fix #2: heredoc, maybe more readable but awkward # https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html#Here-Documents echo <<'EOF' hello ' world EOF ``` PiperOrigin-RevId: 675226634
copybara-service bot
pushed a commit
that referenced
this pull request
Sep 17, 2024
``` # expansion is pretty cool # https://www.gnu.org/software/bash/manual/html_node/Shell-Expansions.html echo "hello `world`" echo "hello ${world}" # single quotes disable expansion # https://www.gnu.org/software/bash/manual/html_node/Single-Quotes.html echo 'hello `world`' echo 'hello ${world}' # Problem - single quotes in single quotes echo 'hello ' world' # Fix #1: quote the single quote, which is exciting echo 'hello '"'"' world' # Fix #2: heredoc, maybe more readable but awkward # https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html#Here-Documents echo <<'EOF' hello ' world EOF ``` PiperOrigin-RevId: 675586161
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.