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 <lrek...@gmail.com> >> wrote: >> >>> On 4 August 2014 16:14, Daniel Pyrathon <pir...@gmail.com> 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 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/47502873-a189-4aa0-8278-c7ab047dfd7f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
