Seems similar to this discussion: https://groups.google.com/forum/#!searchin/django-developers/forms%7Csort:relevance/django-developers/zG-JvS_opi4/wS-4PBfPBwAJ
Yes, signal/slot is a pattern that allows quick and easy decoupling of components that have to work on the same payload, and I've been using happily for at least a decade but I take your point as well. About OVERLOADED_CLASSES, I don't think it's flexible enough, ie. to allow an AppConfig to override a field of another app's form class, that was made possible by David's initial proposal using signals. If we're going to change this bit in Django, I'd like to recommend that we try to cover a broader spectrum of use case, than just allowing a user not to override a url to pass a different form. -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAC6Op18ifztiCqCm1Vr39%2BNGJJpCnu8a3gmYZ8sBMXyGtFZwSg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
