#22712 closed Cleanup/optimization (fixed)
Consider not using built-in functions as parameters
| Reported by: | no | Owned by: | Andreu Vallbona |
|---|---|---|---|
| Component: | contrib.staticfiles | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | no | Triage Stage: | Ready for checkin |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description (last modified by )
Currently the staticfiles finders' find function has a parameter all which is also a built-in function. Personally, I consider using built-ins as parameters/variables to be bad form, and would usually just rename the parameter in my subclasses. Unfortunately, find is explicitly called with all=all in django.contrib.staticfiles.finders.find(). So, to use the built in all() one needs to use from __builtin__ import all as all_.
There are probably more examples throughout the codebase, but this is the one I've run into.
Change History (11)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
| Cc: | added |
|---|
Couldn't the arguments undergo the normal django deprecation cycle? For two version accept both, but issue a warning if the builtin version is used.
comment:3 by , 10 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|---|
| Type: | Uncategorized → Cleanup/optimization |
The all kwarg is a private API, so we can change it. However, we should check whether this is going to break popular third-party addons. (I don't know the staticfiles landscape very well.)
comment:4 by , 8 years ago
| Description: | modified (diff) |
|---|
comment:5 by , 5 months ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
I think I can work on this ticket. I've created a draft pull request PR Let me know what do you think about it.
comment:6 by , 5 months ago
| Has patch: | set |
|---|
comment:7 by , 5 months ago
| Needs documentation: | set |
|---|---|
| Patch needs improvement: | set |
comment:8 by , 4 months ago
| Needs documentation: | unset |
|---|---|
| Patch needs improvement: | unset |
| Triage Stage: | Accepted → Ready for checkin |
| Version: | 1.6 → dev |
comment:10 by , 4 months ago
8719a6181ee6e81282822598e7f14d2d5c9b4c3c is a correction of the deprecation, features deprecated in Django 5.2 should be removed in Django 6.1.
Unfortunately, I think changing this is not going to be worth it, backwards compatibility wise. Will leave it open for a second opinion though.