-
Notifications
You must be signed in to change notification settings - Fork 29.3k
[SPARK-24397][PYSPARK] Added TaskContext.getLocalProperty(key) in Python #21437
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
Changes from 3 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -543,6 +543,15 @@ def test_tc_on_driver(self): | |
| tc = TaskContext.get() | ||
| self.assertTrue(tc is None) | ||
|
|
||
| def test_get_local_property(self): | ||
| """Verify that local properties set on the driver are available in TaskContext.""" | ||
| self.sc.setLocalProperty("testkey", "testvalue") | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should cleanup the property after the test to avoid affecting to other tests?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. there isnt a clear way to clear local property in the spark context? what do you propose is the right approach here? set the local property as "None"? |
||
| rdd = self.sc.parallelize(range(1), 1) | ||
| prop1 = rdd.map(lambda x: TaskContext.get().getLocalProperty("testkey")).collect()[0] | ||
| self.assertEqual(prop1, "testkey") | ||
| prop2 = rdd.map(lambda x: TaskContext.get().getLocalProperty("otherkey")).collect()[0] | ||
| self.assertTrue(prop2 is None) | ||
|
|
||
|
|
||
| class RDDTests(ReusedPySparkTestCase): | ||
|
|
||
|
|
||
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.
If it's missing it will result in a
KeyError, maybe you wantreturn self._localProperties.get(key)which returnsNoneas the default? That seems better to me too, although you might want to add an optionaldefaultvalue.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.
Right.
Uh oh!
There was an error while loading. Please reload this page.
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.
Thanks @BryanCutler for catching this stupid stuff. not at all comfortable with python.
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.
get(key) would return
Nonetho if it's missing.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.
yeah. I added the default=None to make it super obvious. i see no harm in making the code more intuitive.
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.
The Java / Scala equivalents of this API return
nullfor missing keys, so on the one hand returningNoneis kinda consistent with that.On the other hand, consider a case where you want to specify an alternative in case a key is not set:
With this API, you might think of doing something like
tc.getLocalProperty('key') or 'defaultValue', which potentially could be a problem in case a non-None key could have aFalse-y value. I suppose we're only dealing with strings here, though, and that'd only happen for empty strings. If we allowed non-strings to be returned here, though, then we'd have problems if we're returning values like0. For that case, having agetLocalProperty('key', 'defaultValue')is a bit more useful.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.
I am trying to match the Java TaskContext API, which only has a
TaskContext.getLocalProperty(key)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.
FWIW we can always evolve what you have here towards the
getLocalProperty(key, default=None)case; that evolution would maintain behavior and source compatibility. Therefore maybe it's fine to defer that until later if we're not sure whether that variant is useful.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.
Makes sense but +1 for leaving it out since I either don't know how commonly it will be used for now.
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.
Sounds good to me since this matches the Scala API