> This has been resolved by using the ImmutableList datastructure Looks fine. Behaviourally it's the same as a tuple, but with more explicit errors if you attempt to modify it, which seems reasonable.
Given that `.get_fields()` and `.fields` return `ImmutableList`, presumably `.field_names`, `.concrete_fields` and `.local_concrete_fields` should do as well right? > A tuple is *not* "just an immutable list". Interestingly, that's a point where we'd differ. In my mental model a programming construct is defined *purely* by it's behaviour, with no room for any 'conceptual' or 'theroretical' difference - as far as I'm concerned an (unnamed) python tuple really *is* just an immutable python list. I think any further conversation on that is out of the scope of this list, but I've heard both positions advocated, and figured it's an interesting point to note. :) (And it does have the occasional impact on how we'd choose to write documentation examples etc...) All the best & keep up the great work, Tom On Wednesday, 6 August 2014 01:33:53 UTC+1, Russell Keith-Magee wrote: > > > On Tue, Aug 5, 2014 at 12:54 AM, Łukasz Rekucki <[email protected] > <javascript:>> wrote: > >> On 4 August 2014 16:14, Daniel Pyrathon <[email protected] <javascript:>> >> wrote: >> > Hi All, >> > >> > This has been resolved by using the ImmutableList datastructure >> > >> > >> https://github.com/PirosB3/django/blob/soc2014_meta_refactor_upgrade_flags_get_field_tree/django/db/models/options.py#L629 >> > >> >> But why? What's the benefit over using a tuple? ImmutableList is not >> even a list, because it inherits from tuple. >> > > Communication. > > From a purist theoretical perspective, there shouldn't be any argument - > the data we're talking about is a list. Lists have homogeneous elements; > Tuples have heterogeneous elements, but have *positional* homogeneity. A > "Point" is a tuple, because element 0 of the tuple "means" the x > coordinate. A Database row is a tuple - The first element is the primary > key (an integer), second is the "name" column (a string), and so on. > > A tuple is *not* "just an immutable list". > > From a pragmatic perspective, tuples are faster to work with, because they > aren't carrying around all the baggage needed to support mutability. And, > in this case, there is a risk of an end-user accidentally mutating the > result of get_fields(), which, due to cache-related optimizations, means > there's a risk of side effects. > > So - in this case, at a theoretical level, we are dealing with an list of > homogeneous objects (fields) that must be either immutable, or copied every > time it is used. Copying is a bit expensive (not *completely* prohibitive, > but noticeable), so that means we need to look to immutability. At a > theoretical I'm not wild about the fact that ImmutableList subclassing > tuple - it should be subclassing *list* - but I'm willing to defer to > pragmatism. Given that we're dealing with a relative internal detail that > most users won't be exposed to, I'm willing to hold my nose and accept > optimised solutions over theoretically pure solutions in the interests of > *all* users having better performance. > > Yours, > Russ Magee %-) > > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/dd0a4b3d-de5f-4107-8351-dfa2e8bee642%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
