Code

Opened 4 years ago

Closed 2 years ago

#14606 closed Uncategorized (invalid)

Application module imported twice when running development server

Reported by: rlz Owned by: nobody
Component: Core (Other) Version: 1.2
Severity: Normal Keywords: runserver
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I use Django 1.2.3.

I've created a new django project testproject and a new django application test.
I've put the allication inside settings.py, then put only one line of code in test/init.py:

print 'loaded'

And import the applicaton module from application urls.py:

import test

In result the line 'loaded' was printed twice.

This behaviour lead to error in my real project.

Attachments (0)

Change History (10)

comment:1 follow-up: Changed 4 years ago by Keryn Knight <keryn@…>

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

Is this not a function of the project/application being loaded once per process?

What environment are you experiencing this under? manage.py runserver or perhaps a mod_wsgi setup?

comment:2 in reply to: ↑ 1 Changed 4 years ago by anonymous

Replying to Keryn Knight <keryn@kerynknight.com>:

Is this not a function of the project/application being loaded once per process?

What environment are you experiencing this under? manage.py runserver or perhaps a mod_wsgi setup?

I used manage.py runserver

comment:3 Changed 4 years ago by nessita

  • Owner changed from nobody to nessita

comment:4 Changed 4 years ago by nessita

  • Status changed from new to assigned

Confirmed the double import. After some simple, I can confirm that manage.py:execute_manager() is called twice.

The re-entrance point is located within the Command implementation for runserver:

django/core/management/commands/runserver.py(99)

where the autoreload.main(inner_run) method is called. This method spawns a new process that re-executes 'execute_manager()', and this causes the app to be imported twice (since the second time the app is imported is from a different thread, so the import is really executed twice).

I'm not sure how this should be fix, so I'll mark this as 'design decision needed'.

comment:5 Changed 4 years ago by nessita

  • Component changed from Uncategorized to Core framework
  • Keywords runserver added
  • Summary changed from import inside project urls.py import application module twice to Application module imported twice when running development server
  • Triage Stage changed from Unreviewed to Design decision needed

comment:6 Changed 4 years ago by nessita

  • Owner changed from nessita to nodoby
  • Status changed from assigned to new

comment:7 Changed 4 years ago by nessita

  • Owner changed from nodoby to nobody

comment:8 Changed 4 years ago by kmtracey

  • Resolution set to invalid
  • Status changed from new to closed

Loading an app's __init__.py more than once is not a bug. An app should not be coded to expect that its __init__.py will run once and only once. If you have code the must run only once (guessing here since the original report does not actually describe what problem resulted from this behavior) then you need to ensure that happens by some other method than simply putting it in __init__.py and expecting that it will only get loaded once.

comment:9 Changed 2 years ago by ssadler@…

  • Easy pickings unset
  • Resolution invalid deleted
  • Severity set to Normal
  • Status changed from closed to reopened
  • Type set to Uncategorized
  • UI/UX unset

I disagree with the decision to close this ticket. I'm trying to override the admin site, by creating an instance at module level, the same way as is done in django.contrib.admin. It's not working because the module is on the INSTALLED_APPS list as as such gets initialized more than once, causing it to have inconsistent state. I think that the repeated instantiation goes against default Python semantics and also the principle of least surprise, so I'll re-open it for consideration.

comment:10 Changed 2 years ago by anonymous

  • Resolution set to invalid
  • Status changed from reopened to closed

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.