-
-
Notifications
You must be signed in to change notification settings - Fork 31.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
Fixed #22712 -- Avoided name shadowing of "all" in findstatic command. #18259
base: main
Are you sure you want to change the base?
Conversation
d3338d7
to
5d3e09b
Compare
4a27321
to
eabedf1
Compare
@@ -113,17 +113,22 @@ def check(self, **kwargs): | |||
) | |||
return errors | |||
|
|||
def find(self, path, all=False): | |||
def find(self, path, fetch_all=False, **kwargs): |
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'm not familiarized in how deprecations are handled in python/django, but I think that adding **kwargs
is overkill. Maybe add something like:
def find(self, path, fetch_all=False, all=None):
if all is not None:
# TODO: Add a warning or something
fetch_all = all
This sadly doesn't fix shadowing all
, but by adding a deprecation warning it will allow us to remove it in future versions.
Maybe someone can give us some advice on how to handle this?
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 for the feedback @EnriqueSoria. As per your suggestion I've added the deprecations warnings for the use of the all
param in 03b3b1f . On the other hand, I don't see why the use of **kwargs
is an overkill in this case. I think it fits the case, removing the shadowing of the builtin all
function and at the same time avoiding the errors for third party packages that may use or extend the existing finders API. I think using **kwargs
provide us the flexibility we need to keep the backwards compatibility.
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.
When using a function that has **kwargs
you don't know which parameters it does accept. That's why I dislike using it.
But I guess in this case is worth.
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.
Using **kwargs
has the undesired side effect of allowing for arbitrary named arguments and the silently ignoring them. This is something that we should avoid so I see two options:
- Continue using
all
for the deprecation period, is not that terrible since we have already done so for the last 10+ years. - Change to use
**kwargs
but then we should check that no other named param was given and raise the correspondingTypeError
.
I think 1 is the best option, so I would suggest to go down that path.
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.
@avallbona The comment above is what I was referring in the global comment.
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 I missed this comment 😬 . I'm not sure I like the option 1, we don't solve the problem right away and we pospone the solution to a future version, but I think it's clearer on what params the method accepts.
I'll fix it.
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.
Thank you @avallbona for this work! It looks good 🌟
I have added some comments and I also think that we should include release notes in the 5.2.txt
file, under the section Features deprecated in 5.2
. Something like:
* The ``all`` argument for the ``django.contrib.staticfiles.find()`` function
is deprecated in favor of the ``find_all`` argument.
@@ -113,17 +113,22 @@ def check(self, **kwargs): | |||
) | |||
return errors | |||
|
|||
def find(self, path, all=False): | |||
def find(self, path, fetch_all=False, **kwargs): |
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.
Using **kwargs
has the undesired side effect of allowing for arbitrary named arguments and the silently ignoring them. This is something that we should avoid so I see two options:
- Continue using
all
for the deprecation period, is not that terrible since we have already done so for the last 10+ years. - Change to use
**kwargs
but then we should check that no other named param was given and raise the correspondingTypeError
.
I think 1 is the best option, so I would suggest to go down that path.
Addressed the comments in 704fdb9 Thanks for the feedback 🙇🏿♂️ |
Thank you @avallbona for the param rename! Looks great. Did you see my comment about |
I've answered in the comment about |
…in order to avoid shadowing the builtin function **all**.
…l to find_all. Add the deprecation warning in the 5.2 release notes.
warnings.warn( | ||
DEPRECATION_WARNING_MSG, RemovedInDjango60Warning, stacklevel=2 | ||
) | ||
find_all = all |
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 about deleting all
symbol? That way we don't have it shadowed anymore
find_all = all | |
find_all = all | |
del all |
Maybe it's a bit tricky, but it does the job:
>>> all = 3
>>> find_all = 3
>>> all([1,0,1])
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'int' object is not callable
>>> del all
>>> all([1,0,1])
False
>>> find_all
3
Fixed TICKET-22712 - Consider not using built-in functions as parameters.
Trac ticket number
ticket-22712
Branch description
Replaced the name that shadows the builtin funcion all and replaced by fetch_all. I'm not sure if we need the changes to be backwards compatible.
Checklist
main
branch.