Re: set `object = None` on `SingleObjectMixin`

I still haven't seen a definitive reason *why* the mixin doesn't do the check for the object, other than: 'Personally, I don't like this change' Shouldn't the mixin stand on its own and not require going to the django docs to find the dependency that the user needs to set self.object in

Re: Testing Signals

Hi Grant, for future reference django-developers isn't meant as a second level support channel if you don't get a reply on -users. Thanks! On Friday, August 14, 2015 at 5:58:52 PM UTC-4, jdunck wrote: > > I suspect you have 2 different definitions of the signal under different > import paths.

Re: Future of the development server's auto-reloading

LiveReload[1] is one more to consider; what's more it already has examples for Django and other Python frameworks. It relies on Tornado (which may cause some dependency issues? would require testing) but it works. The only tweak that would be required would be to ensure that static files/media

Re: Testing Signals

I suspect you have 2 different definitions of the signal under different import paths. Ensure your python path doesn't have overlapping directories, and that your signal imports refer to the same sys.modules key (e.g. some_app.signals.foo all over, not proj.some_app.signals.foo and

Testing Signals

I posted this in Django users but didn't get any reply. I hope you don't mind me asking here. I does involve Django internals. Simply put, I have an app that has a model that's consumed by other "pluggable" apps. This model will send certain signals during certain events that the pluggable

Re: set `object = None` on `SingleObjectMixin`

Yes, the proposal isn't new. Here is some related discussion: * https://code.djangoproject.com/ticket/21801 * https://github.com/django/django/pull/2260 * https://github.com/django/django/pull/4595 * https://github.com/django/django/pull/4526 On Friday, August 14, 2015 at 3:38:58 PM UTC-4, steve

set `object = None` on `SingleObjectMixin`

In the `SingleObjectMixin` generic view mixin, the `get_context_data` method checks if the object is set by using: `if self.object` I often include this mixin just for the `get_object` functionality and error handing it brings. I end up having to set `object = foo` or `object = None` to

Re: removing FlatPage.enable_comments field?

On 14 août 2015, at 18:22, Shai Berger wrote: > So, what was the field for? Is the purpose still pertinent? If so, since > there are no uses in current code, how is it addressed? I reviewed `git log -S enable_comments`. All occurrences fall in one of three categories:

Re: removing FlatPage.enable_comments field?

On 13 באוגוסט 2015 19:03:09 CEST, James Bennett wrote: >> >The field on FlatPage has been there since the beginning. The >moderation >stuff in the comments app was added later (I originally wrote it as a >third-party app, and it got integrated into contrib.comments

Re: Django's docs application as a reusable app

On Fri, Aug 14, 2015, Jannis Leidel wrote: >Daniele, > >> On 14 Aug 2015, at 13:56, Daniele Procida wrote: >> >> We've been looking at the application used by the Django Project to >build and manage the Sphinx documentation: > >When you say we, who is that?

Re: Django's docs application as a reusable app

Daniele, > On 14 Aug 2015, at 13:56, Daniele Procida wrote: > > We've been looking at the application used by the Django Project to build and > manage the Sphinx documentation: When you say we, who is that? > >

Re: Document/make public prefetch_related_objects

Nothing on `query` is public at the moment - I can see the merit in adding a public API to do this kind of work though. Can you open a ticket? https://code.djangoproject.com/newticket On 14 August 2015 at 13:26, Adam Johnson wrote: > *prefetch_related* is great, but it would

Re: How to disable system check framework?

Marcin - you can "tidy up" some monkey patches, or at least make them robust to the code you're replacing changing, by using https://github.com/adamchainz/patchy . I'm -1 - we've recently been implementing project system checks for our team and they are super useful. We even have one that

Document/make public prefetch_related_objects

*prefetch_related* is great, but it would be nice to be able to reuse its capabilities with lists of model instances already retrieved by other code (or from cache, or newly constructed, etc.). It seems this is possible by using *django.db.models.query.prefetch_related_objects* which is the

Django's docs application as a reusable app

We've been looking at the application used by the Django Project to build and manage the Sphinx documentation: We want similar functionality for some of our own websites, because doing it this way is a much more seamless way than

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

Unless I missed something here, I am strongly -1 on this PR: 1) Form.save(commit=False) is obvious: don't propagate to the database, stop at the object level (I'll manage that later, I don't want to hit the database 2 times, there are some dependencies I need to manage etc). When I read that

Re: removing FlatPage.enable_comments field?

On 12 août 2015, at 00:43, Tim Graham wrote: > A compromise could be to hide the field in the default ModelAdmin and let > those who want it to enable it with a custom ModelAdmin. What do you think? That would resolve my problem of “WTF is this field” without causing too

Re: removing FlatPage.enable_comments field?

On Thursday, August 13, 2015 at 7:03:26 PM UTC+2, James Bennett wrote: > > > As to removing the field from FlatPage, I'm ambivalent enough to be > against it just because removing it is too much effort. But if a stronger > argument can be made for getting rid of it, I could change my mind. > I