Skip to content
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
wants to merge 1 commit into from
Closed

Remove the umbrella import. #1

wants to merge 1 commit into from

Conversation

michaelreneer
Copy link
Collaborator

No description provided.

Copy link
Collaborator

@ZacharyGarrett ZacharyGarrett left a 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.

@michaelreneer michaelreneer deleted the test-pr branch December 19, 2018 04:13
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants