Hey Jeremy, Russ, I've created the working signal now. I have no issue moving the signal to the django.db.models.signals. However, I never planed on sending the models set to be created. I felt that would be an apparent miss direction of the interface. The developer would assume that they'll get a set of models or the model thats being synced.
This raises a question, but before I state said question, I'm happy with what I have now. ( https://github.com/jbcurtin/django/commit/b1bcb93dcd6a64d9c5f2186ef643334febf95e0d) post_syncdb sends the models that have been installed in the database. This would be a naming conflict if I were to name it pre_syncdb, because I only intend to send to connection to each database once. If you're content, Jeremy, with what I've done. I'll generate the necessary docs and then submit a pull request. On Wed, Mar 27, 2013 at 9:48 PM, Russell Keith-Magee < [email protected]> wrote: > Hi Joseph, > > There's no logic that does any such thing. There's nothing unusual or > Django-specific going on here - it's just how Python imports work. > > There is a module called django.core.signals. It contains the definitions > for a bunch of signals related to the core operation of Django, like the > 'connection closed' signal. > > There is also a module called django.db. This module contains the logic > for accessing the database. > > django.db (strictly, django/db/__init__.py) contains the line "from > django.core import signals". That means that the django.db module contains > a "signals" object in its namespace. > > Due to the way Python imports work, you can therefore call "from django.db > import signals" -- because there *is* a signals object in the django.db > module namespace. > > However, The django.db module contains an __all__ declaration, so if you > call "from django.db import *", you *won't* get a signals object -- it's > not explicitly included in the symbol export list for the module. > > As Jeremy said, this is all a moot point anyway. The post_syncdb signal is > defined in django.db.models.signals; if you're adding a post_syncdb > signal, *that* is where it should be defined, and *that* is where you > should be importing it from. > > Yours, > Russ Magee %-) > > On Thu, Mar 28, 2013 at 9:29 AM, Joseph Curtin <[email protected]>wrote: > >> By 'maps to,' I mean that django.core.signals.__file__ clobbers >> django.db.signals.__file__. >> >> Can you point me to the logic that does this? The 'consumer' logic? >> >> >> On Wed, Mar 27, 2013 at 8:35 PM, Jeremy Dunck <[email protected]> wrote: >> >>> I'm not sure what you mean by "maps to". >>> >>> The basic signal framework is in django.dispatcher. If you're >>> implementing https://code.djangoproject.com/ticket/11398 then you >>> probably want to import: from django.dispatcher import Signal. >>> >>> django.db imports django.core.signals because it is a *consumer* of >>> the core signals request_finished and request_started. >>> >>> You probably want to add to django.db.models.signals rather than >>> django.db in any case. >>> https://github.com/django/django/blob/master/django/db/models/signals.py >>> >>> >>> >>> On Wed, Mar 27, 2013 at 4:06 PM, Joseph Curtin <[email protected]> >>> wrote: >>> > Hey all, >>> > >>> > I'm working on adding that pre_syncdb signal, I've come across a >>> rother >>> > peculiar detail. When I import django.db.signals, it maps to >>> > django.core.signals. Am I missing something here? I know for example, >>> > django.conf generates the settings import. Can someone point me to tho >>> logic >>> > of these path edits? >>> > >>> > Cheers, >>> > -Joseph Curtin >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> Groups >>> > "Django developers" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> an >>> > email to [email protected]. >>> > To post to this group, send email to >>> [email protected]. >>> > Visit this group at >>> http://groups.google.com/group/django-developers?hl=en. >>> > For more options, visit https://groups.google.com/groups/opt_out. >>> > >>> > >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at >>> http://groups.google.com/group/django-developers?hl=en. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> >> >> -- >> -Joey Curtin >> http://www.jbcurtin.com >> <http://www.jbcurtin.com>github <http://goo.gl/d5uPH> >> @jbcurtin >> ** >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at >> http://groups.google.com/group/django-developers?hl=en. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers?hl=en > . > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -Joey Curtin http://www.jbcurtin.com <http://www.jbcurtin.com>github <http://goo.gl/d5uPH> @jbcurtin ** -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
