-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
More flexible Python Callable type. #17767
Conversation
R: @ihji |
Codecov Report
@@ Coverage Diff @@
## master #17767 +/- ##
==========================================
- Coverage 74.07% 73.97% -0.10%
==========================================
Files 697 695 -2
Lines 91927 91934 +7
==========================================
- Hits 68092 68010 -82
- Misses 22590 22678 +88
- Partials 1245 1246 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
I didn't realize you wrote the similar PR I drafted last night: https://github.com/apache/beam/pull/17763/files @chamikaramj Cham, Do you have any preference / idea? |
Oh, didn't realize you were looking at this as well. The primary advantage of this form is for anything that is difficult to express as a lambda, e.g. having to write
feels a bit roundabout. I was also leaning towards making things like |
@robertwb Okay. Then can you please add a detailed pydoc about the modified semantics we implemented for a string representation of Python codes? We might need users to know what statements and expressions are allowed and how to use them with examples. |
+1 for simple approach (single string) with a detailed pydoc. From an API perspective I like separating out the exec and eval parts but I agree with Roberts concern that this might feel unnatural for a Python user who just want to use a single Python script that needs some statements to build context. |
Added documentation. |
* function definition (such as {@code def foo(x): ...}). | ||
* | ||
* <p>Any lines preceding the function definition are first evaluated to provide context in which to | ||
* define the function which can be useful to declare inports or any other needed values, e.g. |
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.
imports
* function definition (such as {@code def foo(x): ...}). | ||
* | ||
* <p>Any lines preceding the function definition are first evaluated to provide context in which to | ||
* define the function which can be useful to declare inports or any other needed values, e.g. |
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.
imports
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.
LGTM except one typo. Thanks!
This allows
def
functions, fully qualified imports, and expressions with preambles.Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:
R: @username
).[BEAM-XXX] Fixes bug in ApproximateQuantiles
, where you replaceBEAM-XXX
with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.CHANGES.md
with noteworthy changes.See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)
See CI.md for more information about GitHub Actions CI.