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

DeprecationWarning in ensure_iterable and is_iterable, Closes #6256 #6836

Merged
merged 13 commits into from
May 26, 2024

Conversation

palec87
Copy link
Contributor

@palec87 palec87 commented Apr 13, 2024

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.

Comment on lines 134 to 146
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):
Copy link
Contributor

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the draft PR @palec87

Agree, though I think we would need to make the decision on when it would be deprecated. Given that it is not used this could perhaps be sooner rather than later (0.5.0). What do you think @Czaki?

Copy link
Contributor

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!

Copy link
Contributor

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...

Copy link
Contributor

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.

Copy link
Contributor

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!

Copy link
Contributor Author

@palec87 palec87 Apr 19, 2024

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?

Copy link
Contributor

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.

@Carreau
Copy link
Contributor

Carreau commented Apr 22, 2024

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 ?

@melonora
Copy link
Contributor

melonora commented May 1, 2024

@palec87 As @Carreau pointed out there are some conflicts. If you would like you can resolve them and get the PR out of draft mode. If you are not familiar with resolving conflicts I would also be happy to have a small call with you to show you.

@palec87
Copy link
Contributor Author

palec87 commented May 2, 2024

@palec87 As @Carreau pointed out there are some conflicts. If you would like you can resolve them and get the PR out of draft mode. If you are not familiar with resolving conflicts I would also be happy to have a small call with you to show you.

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.

@melonora
Copy link
Contributor

melonora commented May 2, 2024

Great! What timezone are you in?

@palec87
Copy link
Contributor Author

palec87 commented May 2, 2024

Great! What timezone are you in?

I am UTC+1, free untill lunch for sure.

@palec87 palec87 marked this pull request as ready for review May 3, 2024 08:11
@melonora
Copy link
Contributor

melonora commented May 8, 2024

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.

@melonora
Copy link
Contributor

melonora commented May 8, 2024

however, they are related to the changes. Although at a first glance it seems that allow_none and color have no effect it has some downstream effects on the shapes layer that are not yet all too clear to me.

I tested this after fixing the deprecation warning errors.

@palec87
Copy link
Contributor Author

palec87 commented May 8, 2024

however, they are related to the changes. Although at a first glance it seems that allow_none and color have no effect it has some downstream effects on the shapes layer that are not yet all too clear to me.

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.

@melonora
Copy link
Contributor

melonora commented May 8, 2024

I can push fixes for the deprecation warning and then the actual errors will show. Is it ok if I do so?

@melonora
Copy link
Contributor

melonora commented May 8, 2024

Otherwise I can schedule a short call again and we can go through it together.

@palec87
Copy link
Contributor Author

palec87 commented May 8, 2024

Sure, please push the changes.

@github-actions github-actions bot added the tests Something related to our tests label May 8, 2024
@melonora
Copy link
Contributor

melonora commented May 8, 2024

Ok now you see the actual problem. Particularly the problem occurs here:
https://github.com/palec87/napari/blob/7e558aaec49d5a112e477f51218a512b42d31af1/napari/layers/shapes/shapes.py#L2276-L2312

@melonora
Copy link
Contributor

melonora commented May 8, 2024

if you want we can have a look together

@palec87
Copy link
Contributor Author

palec87 commented May 8, 2024

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.

@melonora
Copy link
Contributor

@palec87 Would you ahve time Friday?

@palec87
Copy link
Contributor Author

palec87 commented May 15, 2024

@palec87 Would you ahve time Friday?

Hi @melonora , yes I think so. Ping me on LinkIn?

…y as True. Fixed conditional accounting for color being an object() posssibly, not only bool
@palec87
Copy link
Contributor Author

palec87 commented May 20, 2024

Hello @melonora, here is my fix. I removed deprecation for allow_none, because it is being set True in stack_utils.py on line 121. Shapes tests were failing because of conditionals when color has been set as object(). Now tests are passing locally.

Copy link

codecov bot commented May 20, 2024

Codecov Report

Attention: Patch coverage is 80.00000% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 92.43%. Comparing base (2102518) to head (96967a9).

Files Patch % Lines
napari/utils/misc.py 80.00% 2 Missing ⚠️
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.
📢 Have feedback on the report? Share it here.

Copy link
Contributor

@melonora melonora left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM now!

@melonora melonora added the ready to merge Last chance for comments! Will be merged in ~24h label May 20, 2024
@melonora melonora added this to the 0.5.0 milestone May 20, 2024
@melonora melonora added the maintenance PR with maintance changes, label May 20, 2024
remove comment
@melonora melonora merged commit 220d3e1 into napari:main May 26, 2024
34 checks passed
@github-actions github-actions bot removed the ready to merge Last chance for comments! Will be merged in ~24h label May 26, 2024
andy-sweet pushed a commit to andy-sweet/napari that referenced this pull request May 28, 2024
…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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
maintenance PR with maintance changes, tests Something related to our tests
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Deprecate/Remove unused arguments from utils functions in napari/napari/utils/misc.py ?
4 participants