On 8 Nov 2015, at 08:31, Marc Tamlyn <marc.tam...@gmail.com> wrote: > I'm definitely in favour of a format allowing multiple storage back ends > referred to by name. For larger sites it is not unusual to manage files > across multiple locations (eg several S3 buckets). The storage param to > FileField would be allowed to be the key, and there would be a get_storage > function like get_cache.
It would remove the assymetry between the default backends and per-field ones, which does feel a little odd. However I don’t think that’s a strong enough reason to go for more complicated. Ballooning dictionaries can feel overwhelming when looking at modern Django settings (for instance, the new templates configuration is more daunting than it used to be), and as pointed out, overriding is more fiddly. For testing, you need to be explicit per-field no matter what, so it’s a change from an instance to a symbolic reference. The instance is probably a variable anyway by declaration of the test model, which I suspect is slightly easier to chase. So I’d be slightly more in favour of the terse, tuple-based syntax. J -- James Aylett I make: devfort.com, spacelog.org Films: talktorex.co.uk Everything else: tartarus.org/james/ -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9462EC40-4D41-4664-A272-D6A9C58DDBB3%40tartarus.org. For more options, visit https://groups.google.com/d/optout.
