also sprach Shai Berger <[email protected]> [2015-12-09 01:20 +0100]:
> class Parent(Model):
>       content_type = ForeignKey('ContentType')
> 
> class Child(Model):
>       parent = ForeignKey(Parent)
>       object_id = IntegerField()
>       # The next does not exist and they want it
>       egfk = ExtendedGenericForeignKey('parent__content_type', 'object_id')

Precisely.

> I suspect that this is a little too baroque for django core, and
> further, it should be possible to implement in user code. Note
> that GenericForeignKey itself is not part of Django core, but
> a contrib app;

Yes, and as noted in my initial mail: I wasn't even sure if turning
to this list was the right thing to do.

> there should be no reason why you cannot do what it does (with the
> only possible exception being admin support).

Yes, I have it all implemented, but it just seems like I am hacking
and duplicating code and it feels aweful. Thus my itch to make the
upstream code more flexible.

> If you try to do that and find that you are missing something, or
> need to use undocumented, private APIs, you'll have a very strong
> case for having those problems solved.

Isn't this enough:

  
https://github.com/django/django/blob/stable/1.9.x/django/contrib/contenttypes/fields.py#L151

It hardcodes the class object and thereby prevents any
subclassing/specialisation/extension, and it's not at all how Python
was designed to work. I understand that the checks framework
requires one to step beyond simple Python duck-typing, but I am not
sure I can be convinced that it's necessary to enforce a specific
model class, when all you need to make sure is that the related
object exposes a specific interface.

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"this week dragged past me so slowly;
 the days fell on their knees..."
                                                        -- david bowie
 
spamtraps: [email protected]

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20151209040738.GB4130%40fishbowl.rw.madduck.net.
For more options, visit https://groups.google.com/d/optout.

Attachment: digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Reply via email to