19

Quoting this answer:

Apart from tuples being immutable there is also a semantic distinction that should guide their usage. Tuples are heterogeneous data structures (i.e., their entries have different meanings), while lists are homogeneous sequences. Tuples have structure, lists have order.

This makes sense to me. But why does Django use tuples and not lists for settings? Example:

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.messages',
    'django.contrib.staticfiles',
)

Isn't this (and all the other settings) a perfect case semantically for a list?

Community
  • 1
  • 1
Flash
  • 15,945
  • 13
  • 70
  • 98
  • 14
    is it an indicator that you cannot install other apps during runtime? – Fabian Sep 10 '12 at 10:37
  • 4
    I think it is because at the time the creator of Django thought they were faster. See this: https://code.djangoproject.com/ticket/8846 – Tom Sep 10 '12 at 11:03
  • Seems that, sort of like what some commenters say on user1474837's link (https://code.djangoproject.com/ticket/8846), the immutability aspect of tuples is perhaps being used as a semantic indicator that Django settings are read-only. If you ignore the incorrect assumption about list vs. tuple performance, that seems the only logical reason left. – JoshMock Sep 10 '12 at 22:00

3 Answers3

14

This was changed in Django 1.9:

Default settings that were tuples are now lists

The default settings in django.conf.global_settings were a combination of lists and tuples. All settings that were formerly tuples are now lists.

https://docs.djangoproject.com/en/1.9/releases/1.9/#default-settings-that-were-tuples-are-now-lists

wannes
  • 151
  • 1
  • 6
  • This seems important to upvote there are lots of tutorials/books out there that are now obsolete on this point. – eric Aug 10 '17 at 16:23
10

Based on user1474837's helpful link to the Django ticket on this question, it seems clear that tuples are used for backwards compatibility with the way settings were done from the start, which was with tuples due to the belief they were faster than lists. (They are, but only very slightly, according to data cited in the ticket discussion.)

Specifically, Django docs used to say:

For settings that are sequences, use tuples instead of lists. This is purely for performance.

Later in the discussion, a Django core developer notes:

We're certainly not about to move from tuples to lists there because it would break existing code that already expects things to be tuples. I'll remove the performance note, however, since it's not worth scaring people.

Note the word "purely" in the original documentation -- which if taken at face value would mean indicating settings are immutable is not a reason tuples are used. Also note someone in the ticket discussion references settings as "sort of" immutable, so it's not even clear settings are in fact immutable.

P.S. For interest, note the ticket resolution ends with:

Changed the "write your own settings" recommendation to mention that Django uses tuples, but not making it a recommendation. That might head off the endless tuples vs. lists debates.

Ghopper21
  • 10,287
  • 10
  • 63
  • 92
2

I think the part of reason is tuple is read-only which will more safe and more suitable for setting.

lvshuchengyin
  • 235
  • 1
  • 4
  • 19
  • What happens if you have common, production and development settings and you want to append e.g. debug_toolbar to common INSTALLED_APPS in your development settings module? – andyn Mar 28 '14 at 07:28
  • Nothing prevents you from doing `FOO_SETTINGS = FOO_SETTINGS + ( another_foo_option, )` on `local_settings.py` if you are loading it at the end of `settings.py`. – Paulo Scardine Jan 28 '15 at 18:51