[Django] #36424: Identically named models in different apps

[Django]

#36424: Identically named models in different apps
-------------------------------------+-------------------------------------
Reporter: john-parton | Type: Bug
Status: new | Component: Core
| (Management commands)
Version: 5.2 | 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
-------------------------------------+-------------------------------------
If you have two models with the same name, the automatic import logic will
result in just one of them being imported.

{{{
$ ./manage.py shell -v2
116 objects imported automatically:

from apps.order.models import Line, Order
from apps.cart.models import Line, Cart

Python 3.13.3 (main, Apr 9 2025, 04:03:52) [Clang 20.1.0 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> Line
<class 'apps.cart.models.Line'>
}}}

shell_plus has a few different ways to resolve this issue: https://django-
extensions.readthedocs.io/en/latest/shell_plus.html#configuration

In my settings.py, I have the following


{{{
SHELL_PLUS_MODEL_ALIASES = {
"cart": {"Line": "CartLine"},
"order": {"Line": "OrderLine"},
}
}}}

To make matters even more annoying, if you have `isort` installed, the
verbose output doesn't even match the expected behavior of the last import
being the ultimately imported symbol.

Output with `isort`


{{{
$ ./manage.py shell -v2
116 objects imported automatically:

from apps.cart.models import Cart, Line
from apps.order.models import Line, Order

Python 3.13.3 (main, Apr 9 2025, 04:03:52) [Clang 20.1.0 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> Line
<class 'apps.cart.models.Line'>
}}}


Note that you do not get a warning even if you run python with `-Wall`

I'm inclined to say that the behavior as-is could be considered a bug.
From the perspective of the user, there's no explicable reason why one
model is picked over the other and there's no indication that such an
overwrite took place. However, this is basically the same behavior as
shell_plus, so perhaps that's being too harsh with django.

Some possible fixes:

1. Document the behavior, maybe here:
https://docs.djangoproject.com/en/5.2/howto/custom-shell/ ; and/or
2. Emit a warning in this case; and/or
3. Don't import either model

Alternatively, implement user configurable "import as" or aliases,
although that's outside the scope of a bugfix and into feature territory.
--
Ticket URL: <https://code.djangoproject.com/ticket/36424>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#36424: Identically named models in different apps
-------------------------------------+-------------------------------------

Reporter: john-parton | Owner: (none)
Type: Bug | Status: new
Component: Core (Management | Version: 5.2
commands) |
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
-------------------------------------+-------------------------------------

Comment (by Clifford Gama):

Thanks for taking the time to create this ticket.

I can reproduce this, but for me this is expected behavior, as documented
[https://docs.djangoproject.com/en/5.2/ref/django-admin/#shell here]:
> Models from apps listed earlier in INSTALLED_APPS take precedence.

That said, the note could benefit from improved wording to make the
meaning more explicit. E.g.
> If multiple apps define models with the same name, the model from the
app listed earlier in INSTALLED_APPS will overwrite any previously
imported model of the same name.

`isort`'s role isn't documented and can easily confuse users trying to
understand why one model was imported over another. I think we should add
a note in the documentation and/or shell command help that the order shown
may be affected by `isort` and may not the order actually used?

Leaving it unreviewed for now so others can weigh in on whether a warning
or automatic resolution for name conflicts is worth pursuing.
--
Ticket URL: <https://code.djangoproject.com/ticket/36424#comment:1>