>>>> 1) get_fields should return a list instead of a tuple >>> Previously, get_fields would return a tuple. The main reason was related to memory and immutability. After discussing with Russell, we decided this endpoint should actually return a list as it is a more suited data structure. >> Can you clarify the reasons for this choice? If it’s just the purity of using the “proper” data type, I’m not sure it beats the practicality of returning an immutable iterable and avoiding the cost of a copy or the risk of incorrect manipulation. > This is a design decision, tuple performs better.
I'm confused - does it return a list or a tuple? Your previous answer mentioned that it was a list, but you later state "This is a design decision, tuple performs better.". Given that it ought to be immutable, I can't see any reason for it *not* to be a tuple. Great work on all of this! All the best, Tom On Sunday, 3 August 2014 15:48:04 UTC+1, Daniel Pyrathon wrote: > > Hi Aymeric, > > Thanks for writing back > > On Sunday, August 3, 2014 4:24:27 PM UTC+2, Aymeric Augustin wrote: >> >> On 3 août 2014, at 15:11, Daniel Pyrathon <pir...@gmail.com> wrote: >> >> *1) get_fields should return a list instead of a tuple* >> Previously, get_fields would return a tuple. The main reason was related >> to memory and immutability. After discussing with Russell, we decided this >> endpoint should actually return a list as it is a more suited data >> structure. >> >> >> Can you clarify the reasons for this choice? If it’s just the purity of >> using the “proper” data type, I’m not sure it beats the practicality of >> returning an immutable iterable and avoiding the cost of a copy or the risk >> of incorrect manipulation. >> > > This is a design decision, tuple performs better. > > >> >> The bugs that would occur if the cached value is altered inadvertently >> could be very hard to track down. >> > > Only a couple of days... > > https://github.com/PirosB3/django/commit/2411ff58d032c38a3151c1e54198723a86e6a8af > > >> >> *2) Move tree cache out of the apps registry* >> The main optimisation for the new API (described here >> https://code.djangoproject.com/wiki/new_meta_api#Mainoptimizationpoints) >> is currently storing information on the Apps registry. After discussing >> with Russell we agree this shouldn't be the correct place to keep this. >> >> >> +1 >> >> A solution is to store related fields information separately on each >> model ( >> https://github.com/PirosB3/django/pull/5/files#diff-98e98c694c90e830f918eb5279134ab9R275). >> >> This has been done, and all tests pass. >> Unfortunately, there are performance implications with this approach: we >> are storing a new list on each model regardless of if it has related fields >> or not. I will be discussing with Russell about performance tomorrow. >> >> >> Is the extra cost incurred only at start up ? How large is it? If it >> isn’t too bad and and run time performance is unchanged, it could be >> acceptable. >> > > Yes! only at start-up. Once cache warming has finished, everything should > be as fast (maybe faster, given that we are accessing properties on the > single Options instance). > > >> >> *3) Revisiting field types and options* >> Last week I opened this: >> https://groups.google.com/forum/#!topic/django-developers/s2Lp2lTEjAE in >> order to discuss with the community possible new field and option names. >> This week I have actually revisited the fields and options for get_field/s >> and I have come up with the following: (…) >> >> >> The latest iteration looks clear, consistent and straightforward. I like >> it. >> > > Thanks! Please feel free to comment with doubts or suggestions. > > >> >> -- >> Aymeric. >> >> -- 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/dad7fb6e-9984-41aa-814e-d373c384b475%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
