Re: Is it a mistake on docs for django 1.5?

2014-01-20 Thread Leonardo Borges Avelino
Thanks for your explanation Baptiste -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group,

Re: Is it a mistake on docs for django 1.5?

2014-01-20 Thread Baptiste Mispelon
Hi, It's actually a bit trickier than that (making the example work required some serious contortions and I wouldn't recommend it in practice). As noted in one of the comments that I added, we can't rely on the default implementation of get_object() because we've overridden get_queryset() to r

Re: Is it a mistake on docs for django 1.5?

2014-01-20 Thread Leonardo Borges Avelino
Yes. It works, but the line: model = Publisher # for SingleObjectMixin.get_object is supressed in this commit. queryset is optional, because it calls get_queryset method, that uses model=Publisher, and IMHO it's better to have model=Publisher than hardcode the queryset I think that we just need

Re: Is it a mistake on docs for django 1.5?

2014-01-20 Thread Tim Graham
Yes, if you check the 1.6 version of the docs, you'll see it's different. I think if this commit were backported to the 1.5 docs, it would remedy the issue. Can you confirm? https://github.com/django/django/commit/e03a88ba217006fbd7618e3f836c2f6210638aaf On Monday, January 20, 2014 3:35:52 PM U

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

2014-01-20 Thread Aymeric Augustin
An interesting related problem hasn’t been raised yet. Since Django 1.7 is much more strict about the import sequence, apps that do stuff at import time will most likely break with RuntimeError("App registry isn't ready yet.”). They will have no choice but to run their initialization in AppConfi

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

2014-01-20 Thread Carl Meyer
Hi Marc, On 01/20/2014 01:23 PM, Marc Tamlyn wrote: > Now I have a moment to mention this, there is a very important issue I > currently don't see a way around, contrib highlights it well but in > reality it's more a third party app issue. > > Suppose my third part app has a (normal) Django two-r

Is it a mistake on docs for django 1.5?

2014-01-20 Thread Leonardo Borges Avelino
Hi fellows I was checking the docs here, and having an error when using SingleObjectMixin in this link: https://docs.djangoproject.com/en/1.5/topics/class-based-views/mixins/#using-singleobjectmixin-with-listview Inside get method, don't I need to pass self to get_object? (yellow below), because

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

2014-01-20 Thread Tim Chase
n 2014-01-20 20:22, Aymeric Augustin wrote: > The alternative is to modify INSTALLED_APPS to support passing > arguments to the AppConfig class. But I find it rather ugly. [I've only been lurking in this thread, so take with a grain of salt; just throwing it out there to see what sticks] Would i

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

2014-01-20 Thread Marc Tamlyn
Now I have a moment to mention this, there is a very important issue I currently don't see a way around, contrib highlights it well but in reality it's more a third party app issue. Suppose my third part app has a (normal) Django two-release support principle. Django 1.8 is coming out and although

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

2014-01-20 Thread Carl Meyer
On 01/20/2014 01:01 PM, Carl Meyer wrote: >>> 3a) As for 3, but use a flag on the AppConfig subclass that marks >>> it as "use me as the default". If there are more than one AppConfig >>> objects in an apps module that has the 'use as default" flag, raise >>> an error. >> >> This smells like depend

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

2014-01-20 Thread Carl Meyer
Hi all, I just filed #21831, which is a release-blocking regression directly related to this. My opinion is that doing check-registration as an import side-effect in `__init__.py` is not viable, as it means that every single check needs to be coded defensively against the possibility that the app

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

2014-01-20 Thread Carl Meyer
On 01/20/2014 12:22 PM, Aymeric Augustin wrote: > On 20 janv. 2014, at 18:36, Carl Meyer wrote: > >> I very much hope >> that moving the admin autodiscovery to the admin AppConfig still allows >> some reasonable path to opt-out of autodiscover - perhaps by subclassing >> the admin AppConfig? > >

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

2014-01-20 Thread Aymeric Augustin
On 20 janv. 2014, at 18:36, Carl Meyer wrote: > I very much hope > that moving the admin autodiscovery to the admin AppConfig still allows > some reasonable path to opt-out of autodiscover - perhaps by subclassing > the admin AppConfig? We could provide AdminAutoDiscoveryConfig and AdminConfig.

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

2014-01-20 Thread Carl Meyer
On 01/19/2014 07:08 AM, Aymeric Augustin wrote: > On 19 janv. 2014, at 13:46, Russell Keith-Magee > wrote: > >> On Sun, Jan 19, 2014 at 5:48 PM, Aymeric Augustin >> > > wrote: >> >> Also there might be good reasons for

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

2014-01-20 Thread Jannis Leidel
On 19.01.2014, at 08:56, Russell Keith-Magee wrote: > Hi all, > > First off - this isn't critical for 1.7 alpha - I'm raising it now because > I've been in this space for the last couple of days as a result of the > working on the check framework. I suspect any changes stemming from this > di