Application init inconsistent

39 views
Skip to first unread message

Scott Sadler

unread,
May 7, 2012, 4:29:34 PM5/7/12
to Django developers
Hi all,

I'm making some extensions to the Django AdminSite for dashboard I'm
working on, and I have a couple of questions. My urls.py looks
something like this:

from django.utils.importlog import import_module
from django.contrib import admin

my_admin = import_module('my.admin')
# monkeypatch admin.site so that autodiscover and subsequent
imports reference my site instance
admin.site = my_admin.site
admin.autodiscover()

In each application's admin.py that uses the custom extensions, I
import the admin object directly from my.admin, so that imports wont
break in isolation.

This is only working because I do the import using import_module. If I
do it the normal way, my site object is initialized twice; the module
is re-imported at some point during autodiscover and the subsequent
imports point to the wrong instance.

Questions:

1: Is there a better way to extend the admin site that I'm missing? If
not:
2: Shouldn't this work without hacking the import in urls.py? It took
me a while to track this down, and it feels a bit wrong to me for the
following reasons:
* It was surprising to see my site with 2 different object ids being
generated for one __init__.py.
* Python supports module level mutable state, Django should respect
that for 3rd party applications, as well as it's own.

I'm also not aware of the precise reason that this is not working (why
is the import done twice?).

Thanks,

Scott

Alex Ogier

unread,
May 8, 2012, 12:33:20 PM5/8/12
to django-d...@googlegroups.com

My guess is that Django is doing some normalization on the name you are importing. It does this to prevent double imports, for example importing 'projectname.appname' and 'appname' which would otherwise be considered separate modules even if they come from the same source.

Just a theory, but it explains the behavior you are seeing if you are importing a different name when you do the native import.

Best,
Alex Ogier

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Jeremy Dunck

unread,
May 8, 2012, 1:30:47 PM5/8/12
to django-d...@googlegroups.com
On Tue, May 8, 2012 at 9:33 AM, Alex Ogier <alex....@gmail.com> wrote:
> My guess is that Django is doing some normalization on the name you are
> importing. It does this to prevent double imports, for example importing
> 'projectname.appname' and 'appname' which would otherwise be considered
> separate modules even if they come from the same source.
>
> Just a theory, but it explains the behavior you are seeing if you are
> importing a different name when you do the native import.

This is correct, but it's generally a bad idea to have overlapping
import paths due to this double-import problem.

I wrote this wart remover some time ago - it might help spot the problem:
https://gist.github.com/857091
Reply all
Reply to author
Forward
0 new messages