On Wednesday, August 6, 2014 3:46:42 PM UTC+2, Tom Christie wrote: > > > 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? >
Of course, I am pushing a new version of this now > > > 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]> >> wrote: >> >>> On 4 August 2014 16:14, Daniel Pyrathon <[email protected]> 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/47502873-a189-4aa0-8278-c7ab047dfd7f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
