Query about inheritance clash in models

I've a specific set of models: class Parent(models.Model): pass class ChildA(Parent): pass class ChildB(Parent): pass Here Parent has fields: (, , ) and ChildB has fields: (, ) so fields childa and childb are not inherited in ChildB, which is normal and expected. But adding

3 level nested prefetch is not working as expected on Django 1.8.x

Posting this from django-users https://groups.google.com/forum/#!topic/django-users/v3KelvexqiI. Three level nested prefetch with custom queryset throws an Attribute Error. > It works perfectly fine on Django 1.9 but I was unable to find release > notes or bug fix notes of the same. > > To rep

Re: thinking about the admin's scope and its description in the docs

On Wed, 10 Feb 2016 at 13:55 Andy Baker wrote: > I can't help but feel that the "admin is very rudimentary and hard to > customize" is perpetually overplayed by many in the community. Maybe I'm > suffering Stockholm Syndrome but I'd like to raise a dissenting voice. > > I find it the quickest and

Re: thinking about the admin's scope and its description in the docs

On Tue, 9 Feb 2016 at 23:25 Tim Graham wrote: > The introduction to the admin in the docs [0] reads: > > "One of the most powerful parts of Django is the automatic admin >> interface. It reads metadata in your model to provide a powerful and >> production-ready interface that content producers ca

Re: Changing the primary key of Django models

Yes you can keep custom primary key. Pass `primary_key=True` in your model and Django won't create a primary key for that model. Here are relevant docs: https://docs.djangoproject.com/en/1.9/ref/models/fields/#django.db.models.Field.primary_key On Fri, 5 Feb 2016 at 20:52 Uri Even-Chen wrote: >

Re: Remove null assingment check for non-nullable fields?

With respect to rationale 2: It makes sense to remove this check as database handle these checks very well. And just like uniqueness checks, it is nice to let database do its work. With respect to rationale 1: Since this behaviour will ask developers to change exception catching from ValueError to

Re: Proposal: add new template tag "age"

If we ever need to implement age filter, I would rather suggest for modification of naturaltime in django.contrib.humanize to take an optional parameter (age = True). On Tue, 10 Nov 2015 at 01:22 Tim Graham wrote: > For questions of whether or not to include something like this in core, my > own

Re: User.username max_length 254

Hello All, Since username length is going to increased from 30 to 254 (PR #5497 ), I personally think first_name and last_name field length should be increased as well. Practically many first names are of length > 30, this is quite common in southern

Re: Should contrib.auth include support for 2fa out of the box?

Other then u2f and TOTP, I'll favour for email and sms (using external api like twilio) based OTP as well. Keeping different pluggable backends will be better in my opinion. On Tue, 27 Oct 2015 at 07:01 Russell Keith-Magee wrote: > > +1. Sounds like a great idea to me. > > Russ %-) > > On Tue, O

Re: Python 3.5 Support in Django 1.8.x?

In my opinion adding 3.5 support to 1.8 makes sense since 1.8 is LTS and by the end of 2018 we'll have python 3.6 and 3.7 as well On Sat, 24 Oct 2015 at 03:28 Marc Tamlyn wrote: > FWIW, I think we should add 3.5 support to 1.8. > > On 23 October 2015 at 17:08, Tim Graham wrote: > >> Officially

Re: Why passing request, *args, **kwargs in dispatch method for generic views

>>> deprecation path and could result in a lot of churn in user code which >>> would probably cause some angst. I'll leave it to users of CGGVs to offer >>> an opinion on whether or not it could be worthwhile. >>> >>> On Friday, October 23, 2015

Re: #25582: Add a way to build URLs with query strings

How about a wrapper over reverse? Modifying reverse will lead to multiple changes in core urlresolver. A class based urlresolver can be implemented which will call reverse internally. On Friday, 23 October 2015 17:29:25 UTC+5:30, guettli wrote: > > API proposal: > > Add a new kwarg to revers

Why passing request, *args, **kwargs in dispatch method for generic views

Hello all, With reference to this line: https://github.com/django/django/blob/master/django/views/generic/base.py#L61 from django.view.generic.base before calling self.dispatch request, args and kwargs attributes have been added to self. So these all are available in self in http_method handle