Why does Django use tuples for settings and not lists?

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:


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


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.

Need Your Help

How to make a range absolute with offset functions in excel?

excel range offset vlookup

I have defined a dynamic range using OFFSET function in Excel, and I use it in VLOOKUP function to lookup a value:

android consolidating views in include statements, improve performance?

android performance memory layout view-hierarchy

I am optimizing my android layouts. One suggestion I got was to re-use layouts in include statements. Although I understand the utility of this, kind of like object orientated views, but does it