Would it be possible to have some sort of registration pattern, allowing people to import per-backend and per-project libs to override and extend the various available functions?
I realise this is nothing more than a sanctioned form of monkey patching, but it would at least provide a common pattern for people to do so, and hopefully make the whole process more manageable and predictable. -- Curtis On 18 June 2014 17:09, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote: > On Wednesday, June 18, 2014 4:52:11 AM UTC+3, Josh Smeaton wrote: >> >> Over the last 6 months we've been working on a fairly large refactor to >> expressions. As a brief catch up, expressions are currently F() >> expressions. I've expanded their scope to include Aggregates. As a >> by-product of this we can now use any kind of expressions in the >> .annotate() function, not just aggregates. Tim Martin has done some work >> based on this patch that extends support to .order_by() also. See the >> bottom of this post for links to the various discussions and patches. I >> highly recommend reading them - and for 3rd party backend maintainers - >> trying them out. >> > > Not just 3rd party backend maintainers, but also for 3rd party library > writers. The new way could break your code if you depend on current > implementation of ExpressionNode, aggregates or SQLEvaluator. > > I think finding a small subset of commonly used functions and including > them in core or contrib is a good idea - these should be building blocks > every Django application can depend on. The main problem is how to limit > that subset. > > 5. Are we jumping the gun and should we wait until the patches land before >> even discussing the above? >> > > Maybe a bit - maybe it is better to wait and see what happens to the > expressions refactor idea. It is interesting to see that the expressions > refactor patch has led to multiple discussions about how to use it for > other new features. So, expressions refactor is definitely doing something > right. > > - Anssi > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" 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 http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/daf867fe-bedf-4134-bc92-728e2fa2c17f%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/daf867fe-bedf-4134-bc92-728e2fa2c17f%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers" 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAG_XiSCQucYt98Vyzdt_TiQDSiFrr%3D4rLpSmDbHXbxWv%2B6_P%3Dw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
