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.
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
Enhance Python LivenessScope API #4497
Enhance Python LivenessScope API #4497
Changes from 9 commits
e143677
6276e80
81eeae0
7b1ee54
0b252f2
13dd0df
939ae34
9721921
32dd881
3079dde
7a94403
d0e8c83
5a800b1
3dd3774
fdf1ca4
9115098
f1c90ef
b8c890a
7e456b7
5ddb965
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 don't see where
DeprecationWarning
is being imported.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.
Welcome to python I guess? its already imported by default for some reason: https://docs.python.org/3/library/exceptions.html?highlight=deprecationwarning#DeprecationWarning
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.
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.
Deprecated, to be removed.
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 these use cases are likely to fail, should we just hard remove these warning cases?
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 advantage (I leave it to you/Jianfeng if this is a good one or not) that the deprecation warning will tell you what to fix, but just removing the method will just break and let you sort it out yourself.
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.
Reading this, I have some concerns. It seems like both
and
work, since
open
returns aLivenessScope
, but only the second releases properly. I'm concerned that this design may create a construct that doesn't force the user to always do the right / smart thing.At the same time, the syntax feels more awkward.
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.
Both "work" (after
s/LivenessScope/livenessScope/
), in that the first one will warn "you're doing it wrong, this will not work correctly", thus "strongly encouraging" the user to call open(). We can outright remove this right away and do away with deprecation warnings, or wait a version or two for anyone who happens to be using this and needs to transition away.The new version is strictly more powerful, as it doesn't conflate creating/releasing a scope with adding/removing it on the stack. We can't really have it both ways... The other option (discussed with Ryan) is to make open() an optional step so that you can call it either way, but this makes the Java and Python usage different/confusing going back and forth.
One other option is that we deprecate liveness_scope() itself, and make the LivenessScope() constructor usable, so we can leave liveness_scope() intact.
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.
yield
below does appear to return aLivenessScope
, so it isn't clear how it would be None.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.
missing type info
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.
missing type info
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.
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.
missing type info
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.
@jmao-denver would it make sense to take this away (or deprecate it) and just encourage the LivenessScope constructor instead?
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 was going to ask something similar. How do we minimize the syntax complexity and length while still feeling Pythonic? Maybe we want to keep this method and have it take the
open
args. Then users could just do something like: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.
Dropping this in favor of just a regular ctor call, updating class docs
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
liveness_scope
pydoc indicates that@liveness_scope
can be used to control scope, but I don't see a test for this case.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.
added (and otherwise cleaned up tests a bit).
typehints were wrong for both contextmanager usages, i fixed them as well.
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.
self._liveness_scope
does not appear to be used. Can it be removed?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.
Yes, I missed that.
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.
This syntax feels worse than what we had before. Can it be improved?
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.
What we had before was too simple, and prevented an important use case: Keeping a LivenessScope around in order to fully control the life cycle of the objects created under it, and/or re-using the same LivenessScope on multiple calls. That is, the old API was simply not fit for purpose.
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.
This particular case is bad, because apparently the unittest "fixtures" can't be wrapped in contextmanagers or a
with
expr, etc - you can only explicitly open something, then close it later. That isn't a pattern we want to encourage here, since you might screw up and not close it. Apparently pytest does this better, closer to how junit solves this.The other changes made in this patch's tests are more representative of how we expect this to work.