[Django] #35224: Make GenericForeignKey subclass Field

[Django]

#35224: Make GenericForeignKey subclass Field
------------------------------------------------+--------------------------
Reporter: Adam Johnson | Owner: nobody
Type: Cleanup/optimization | Status: assigned
Component: contrib.contenttypes | Version: dev
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
------------------------------------------------+--------------------------
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` is confusing. It is added as a
“field” and returned by `Model._meta.get_fields()`, a type confusion
[https://github.com/typeddjango/django-
stubs/blob/5a8e7b3855ea6f7be2b2ab928d02eff9a748d917/django-
stubs/db/models/options.pyi#L122-L124 reflected in django-stubs]. It also
duplicates code from `Field`.

I think we should make it a subclass of `Field`.
--
Ticket URL: <https://code.djangoproject.com/ticket/35224>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#35224: Make GenericForeignKey subclass Field

-------------------------------------+-------------------------------------

Reporter: Adam Johnson | Owner: nobody

Type: | Status: assigned
Cleanup/optimization |
Component: | Version: dev
contrib.contenttypes |
Severity: Normal | Resolution:

Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0

-------------------------------------+-------------------------------------
Description changed by Adam Johnson:

Old description:

> 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` is confusing. It is added as a
> “field” and returned by `Model._meta.get_fields()`, a type confusion
> [https://github.com/typeddjango/django-
> stubs/blob/5a8e7b3855ea6f7be2b2ab928d02eff9a748d917/django-
> stubs/db/models/options.pyi#L122-L124 reflected in django-stubs]. It also
> duplicates code from `Field`.
>
> I think we should make it a subclass of `Field`.

New description:

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:
1. It is added as a “field” and returned by `Model._meta.get_fields()`, a

type confusion [https://github.com/typeddjango/django-
stubs/blob/5a8e7b3855ea6f7be2b2ab928d02eff9a748d917/django-
stubs/db/models/options.pyi#L122-L124 reflected in django-stubs].

2. It duplicates code, such as `_check_field_name()`.
3. It misses methods like `__repr__()`.

I think we should make it a subclass of `Field`.

--

--
Ticket URL: <https://code.djangoproject.com/ticket/35224#comment:1>