Hi All, This week I have been working on mainly 3 tasks:
*- Formalizing the PR* 2 days were dedicated on fixing all the small issues on the PR. I am now ready for another review. *- Simplified the API for get_field* There are 3 used combinations of get_field() in the entire Django codebase - get_field(data=True, m2m=True) > 60% of the occurrences - get_field(data=True, m2m=True, related_objects=True, related_m2m=True, virtual=True) > 39.9% of the occurrences - get_field(data=False, m2m=True) once only! (0.01% of occurrences). The new API replaces the first 2 cases by generalizing: get_field(field_name, include_related=False, **kwargs). The API is still 100% backwards compatible with the old API, until Django 2.0. Benefits: - better and simpler API - better memory management (caching) *The mailer* As my final deadline is near, I continued working on the mailer. The mailer is a custom store that allows Django admin and forms to interact with the GMail API. I have published the source code for this here: https://github.com/PirosB3/django-mailer/ While the code is still "a big hack", I aim on getting a PoC fully working and then do some refactoring. This week I managed to get relations between custom models working, *all using the new Options API! *The result is I can now browse my mail through the admin panel! <https://lh6.googleusercontent.com/-5lUx63hvlZw/U-Yprxl8AzI/AAAAAAAALg0/8qNh6qw3YtA/s1600/5512779.png> *- Help me get people excited about this!* The new Options API works, and allows developers to create custom stores. This will allow us to create official NoSQL stores, SqlAlchemy stores, and even a IMAP store. I think it's a great feature that has the potential to make Django more decoupled and more powerful. Said this, it still needs loads of work. And I am sure the API can still improve. Let's get more people aware of the new possibilities and help me make a better API: - You can retweet https://twitter.com/pirosb3/status/497701148665843715 - You can review https://github.com/django/django/pull/2894 Thanks! Daniel On Friday, August 8, 2014 6:37:06 PM UTC+2, Daniel Pyrathon wrote: > > > > 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/c7a53059-a65a-486e-9edf-01e6e2ce84d2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
