Opened 21 months ago
Last modified 21 months ago
#35224 closed Cleanup/optimization
Make GenericForeignKey subclass Field — at Version 1
| Reported by: | Adam Johnson | Owned by: | nobody |
|---|---|---|---|
| Component: | contrib.contenttypes | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | 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 )
When introduced in bca5327b21eb2e3ee18292cbe532d6d0071201d8, GenericForeignKey was created as its own class. Since then, it has grown to resemble a field, particularly in fb48eb05816b1ac87d58696cdfe48be18c901f16.
GenericForeignKey *not* being a Field leads to several issues:
- It is added as a “field” and returned by
Model._meta.get_fields(), a type confusion reflected in django-stubs. - It duplicates code, such as
_check_field_name(). - It misses methods like
__repr__().
I think we should make it a subclass of Field.
Note:
See TracTickets
for help on using tickets.