As it so happens, someone else ended up tackling this problem for a different use case in https://github.com/django/django/pull/6233.
There's a small design discussion on the pull request about how to structure OPTIONS (possibly deprecating the current behavior of pylibmc that passes them directly to client.behaviors) if anyone would like to weigh in. On Monday, February 22, 2016 at 1:36:02 PM UTC-5, Claude Paroz wrote: > > Le lundi 22 février 2016 13:00:31 UTC+1, Ed Morley a écrit : >> >> (...) >> >> I'm happy to put together a PR to make the impact/complexity easier to >> judge, if that helps? >> >> > Yes, it always help to see the code. > > >> Before I do that I would just need to know whether the `username`, >> `password` and `binary` fields should be added to the top level >> `CACHES['foo']` dict, or nested inside `OPTIONS` within that? Examples: >> https://emorley.pastebin.mozilla.org/8858134 >> > > I would say that if username and password are not mandatory, put them in > options. But no strong opinion here. > > Claude > -- 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/95987755-0ade-4c3d-a806-52f1b3393af5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
