Re: __ne, #5763

Hi Marcin, Am Samstag, 21. November 2015 02:22:10 UTC+1 schrieb Marcin Nowak: > > On Friday, November 20, 2015 at 8:37:02 PM UTC+1, Carsten Fuchs wrote: >> >> sorry if this is a stupid question, but after having read >> https://code.djangoproject.com/ticket/5763 and the discussions linked >>

Re: __ne, #5763

Hi James, Am Samstag, 21. November 2015 02:56:45 UTC+1 schrieb James Bennett: > > 8 years later, I still think we should figure out how to make exclude() do > what people expect it to do, rather than implement another lookup type that > overlaps with it. > What really confuses me is how

Re: __ne, #5763

Am Samstag, 21. November 2015 02:27:42 UTC+1 schrieb Aaron C. de Bruyn: > > With all due respect, looking through the ticket and reading responses > shows me that the 'pro' side has good use cases for __ne, and the 'con' > side basically says "use exclude" or "a core committer close the ticket,

Re: __ne, #5763

The 'con' side argument is that it would create in inconsistency in the API, since we don't have any other negated lookups either. If we can get the same behaviour by fixing the current API, Django should not introduce an unnecessary consistency. ("Closed as wontfix by core dev" is not an

Re: __ne, #5763

Hi Marten, Am 2015-11-21 um 11:53 schrieb Marten Kenbeek: The 'con' side argument is that it would create in inconsistency in the API, since we don't have any other negated lookups either. If we can get the same behaviour by fixing the current API, Django should not introduce an unnecessary

Re: __ne, #5763

On Saturday, November 21, 2015, Carsten Fuchs wrote: > Hi Marten, > > Am 2015-11-21 um 11:53 schrieb Marten Kenbeek: > >> The 'con' side argument is that it would create in inconsistency in the >> API, since we don't have any other negated lookups either. If we can get >>

Re: __ne, #5763

Hi Anssi, Am 2015-11-21 um 12:50 schrieb Anssi Kääriäinen: In summary, the imaginary query of comment 14 Blog.objects.filter(entry__tag__name='django', entry__author_count__ne=2) This isn't a real query. There isn't a field author_count, the query needs an annotation

Django-oscar PicklingError caused by None session on submit

Hello everyone, Thank you for reading this ! I am a 3 weeks newbie in django. I occurred a picklingerror when integrating qrcode payment(wechat payment) with django-oscar. *Steps cause the promblem:* 1. Add a product in basket and chose to pay directly; 2. Chose payment method;

Re: Django-oscar PicklingError caused by None session on submit

Please write to django-users (as I see you already did) as this mailing list is for the development of Django itself. It isn't a second level support channel if no one answers your post there. On Saturday, November 21, 2015 at 10:26:13 AM UTC-5, 张小西 wrote: > > Hello everyone, > Thank you for

Re: __ne, #5763

I hadn't come across custom lookups in the docs. Thanks for the explanation and a fix Marten, I appreciate it. -A On Sat, Nov 21, 2015 at 2:53 AM, Marten Kenbeek wrote: > The 'con' side argument is that it would create in inconsistency in the > API, since we don't have

Re: __ne, #5763

I have to say, the lack of __ne is very inconsistent for people new to django, but veterans at sql. It's just one more frustration point when you're trying to learn a new ORM. -Ben On Friday, November 20, 2015 at 11:37:02 AM UTC-8, Carsten Fuchs wrote: > > Hi all, > > sorry if this is a

Fellow Report - November 21, 2015

Triaged --- https://code.djangoproject.com/ticket/25757 - Don`t create session automatically for anonymouse user (duplicate) https://code.djangoproject.com/ticket/25763 - Django missing repr friendly formatting of request (wontfix) https://code.djangoproject.com/ticket/25775 - Method

Re: "Project" vs "App"

I'm not sure about saying that a project is a "container for apps", and that a project contains "only" settings and "no database models". At a basic level, a "project" can be just a settings module, but it may include other things. Apps that are sub-packages within a project are generally not