-
-
Notifications
You must be signed in to change notification settings - Fork 410
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
DeprecationWarning in ensure_iterable and is_iterable, Closes #6256 #6836
Conversation
napari/utils/misc.py
Outdated
can either be a single value or a list. If a color is passed then it | ||
will be treated specially to determine if it is iterable. | ||
can either be a single value or a list. | ||
Argument color is deprecated. | ||
""" | ||
if is_iterable(arg, color=color): | ||
# deprecate color | ||
if color: | ||
warnings.warn( | ||
trans._( | ||
'Argument color is deprecated.', | ||
), | ||
category=DeprecationWarning, | ||
stacklevel=2, # not sure what level to use here | ||
) | ||
if is_iterable(arg): |
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.
You likely want to do something like:
sentinel = object()
def ensure_iterabel(...., color = sentinel):
if color is not sentinel:
warning.warn...
This way the warning is triggered even if color=False
is passed.
another way is to do
def ensure_iterable(..., *args, **kwargs):
and then check the content of args and kwags, but it's a bit more verbose.
You likely also want to say either since when it's deprecated, and/or when it will be removed I think.
I'm not that involved in the project anymore but other dev will likely pitch in. Check with them.
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.
Deprecation warnings have to be released at least once so people can see them, so we can't deprecate in 0.5.0!
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.
Deprecation warnings have to be released at least once so people can see them, so we can't deprecate in 0.5.0!
Are yon confusing Deprecation and Removal ?
I mean most of the "Deprecated in X" are emitted for the first when doing release X...
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.
Targeted for deprecation from 0.5.0, but then deprecated before 0.6.0 given that these are not used.
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.
Sorry, indeed getting confused, ignore my brainfart :P Yes, deprecate in 0.5.0 is good!
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.
Thank you @Carreau, I have already learned something new. @melonora, with my new commits, if I understand the deprecation logic, I returned the original color/allow_none argument functionality and only marked it for removal in 0.6.0. It does not change the runtime, because it is not used, however it should be removed only after 0.5.0 release, right?
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 @palec87, it seems good to me. The stacklevel determines how many calls to unwind so it is good not to get this number too high.
…ocstrings with deprecation in 0.5.0 and removel in 0.6.0. Put back the color functionality
Thanks, the new logic looks good to me – but I not a core dev so it's not my role to decide if this is ok. I would mark this as ready for review. This seem to have picked up conflicts with the main branch. @palec87 are you familiar with merging with/rebasing on main and fixing merge conflicts ? |
Hi @melonora, I would like to go with the call and not messing up. Perhaps tomorrow 3/5? Thanks for help @Carreau too, very appreciated. |
Great! What timezone are you in? |
I am UTC+1, free untill lunch for sure. |
for more information, see https://pre-commit.ci
Hi @palec87, I see that some tests are failing due to the deprecation warning. I am implementing some minor fixes for those. These are not related to the merge. |
however, they are related to the changes. Although at a first glance it seems that I tested this after fixing the deprecation warning errors. |
Hi @melonora, I see, do you think it is because of the Deprecation warning? Your testing means running the pytest locally, or something else? To me it looks like test_ problem, not shapes layer probles. However, I did not see the -W option for pytest which would result in such errors. |
I can push fixes for the deprecation warning and then the actual errors will show. Is it ok if I do so? |
Otherwise I can schedule a short call again and we can go through it together. |
Sure, please push the changes. |
Ok now you see the actual problem. Particularly the problem occurs here: |
if you want we can have a look together |
I see know, pretty deep for me, but I have 30 mins, if you want to show me. |
@palec87 Would you ahve time Friday? |
…y as True. Fixed conditional accounting for color being an object() posssibly, not only bool
Hello @melonora, here is my fix. I removed deprecation for |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #6836 +/- ##
==========================================
+ Coverage 92.31% 92.43% +0.11%
==========================================
Files 613 613
Lines 55176 55180 +4
==========================================
+ Hits 50936 51003 +67
+ Misses 4240 4177 -63 ☔ View full report in Codecov by Sentry. |
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 now!
remove comment
…6256 (napari#6836) # References and relevant issues Supposed to Close napari#6256. I am not sure about the stacklevel arg of the warning. # Description Added DeprecationWarning if arguments passed and removed the functionality related to them within the functions. # Regarding checklist I am not sure about the docs repo. --------- Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> Co-authored-by: Wouter-Michiel Vierdag <michiel.vierdag@embl.de> Co-authored-by: Wouter-Michiel Vierdag <w-mv@hotmail.com>
References and relevant issues
Supposed to Close #6256. I am not sure about the stacklevel arg of the warning.
Description
Added DeprecationWarning if arguments passed and removed the functionality related to them within the functions.
Regarding checklist
I am not sure about the docs repo.