Also, I still believe that just because "class Meta:" stole the word
"meta", doesn't mean we should take what it should really be called
("options") and put it on this. Can we call the two "meta options api" and
"meta fields api"? or "meta schema api".
--
You received this message because you
Summarizing the conversation I just had with Daniel in IRC:
What if we thought about just documenting the high-level api, like what
ModelForms uses, and not necessarily document what the django low levels:
ORM, migrations, etc would need to use.
Could we get away with not documenting _meta.get_fie
Hi All,
Since last week, the new API has changed: we went from 5 field types to 9
field types. Below is a list of all field types, the bold ones are the ones
that have just been added.
* pure data (CharField etc)
* * relation data (FK)*
* pure virtual (Point)
* * relation virtual (GFK)*
* m2
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
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 `.g
> 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`, `.
Hi Łukasz,
Sorry for getting back to you now. Thanks Russell for the comments.
As Russell says, it's more of a conceptual choice. My first implementation
of this API was using tuples for the same
reason you said above. I think ImmutableList is a good compromise between
list and tuple. It overrid
> On Aug 6, 2014, at 7:14 AM, Collin Anderson wrote:
>
> 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* homogene
>
> 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 t
On Tue, Aug 5, 2014 at 12:54 AM, Łukasz Rekucki wrote:
> On 4 August 2014 16:14, Daniel Pyrathon 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/d
On 4 August 2014 16:14, Daniel Pyrathon 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 tu
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
On Monday, August 4, 2014 2:44:38 PM UTC+2, Collin Anderson wrote:
>
> if we do really need a list, c
if we do really need a list, could we gain some performance by caching
tuples and converting them to lists instead of caching lists?
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails f
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
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 >
> wrote:
>
> *1) get_fields should return a list instead of a tuple*
> Previously, get_fields would return a tuple. The main reason was related
On 3 août 2014, at 15:11, Daniel Pyrathon 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 li
Hi All,
First of all Thank you SO MUCH for your comments. It's really nice to hear
great feedback from the community.
These last two weeks I have been working on improving the existing API
implementation and terminology. Here is an overview of the 3 main tasks:
*1) get_fields should return a li
On Sat, Jul 19, 2014 at 2:38 AM, Raffaele Salmaso
wrote:
> On Fri, Jul 18, 2014 at 7:32 PM, Daniel Pyrathon
> wrote:
>
>> *- Started on my GMail Store*
>> (...)
>>
> Pirosb3, just three words: really nice work!
>
>
I absolutely agree! The possibilities are endless.
Congratulations on deliverin
On Fri, Jul 18, 2014 at 7:32 PM, Daniel Pyrathon wrote:
> *- Started on my GMail Store*
> While I was waiting for review, I have started an implementation of my
> GMail store. The implementation is documented here (
> https://docs.google.com/document/d/1yp2_skqkxyrc0egdRv6ofnRGCI9nmvxDFBkCXgy0Jwo
Hi All,
As usual, here are my updates:
*- Formalised pull request, looking for a formal review*
Last week I published the wiki page for my meta implementation. This week I
have been working on improving internal code documentation, optimising a
few bits and bobs, and added the formal documentat
Hi All,
Following this week's work. I have made progress in optimisation and design
of the API.
I have opened a wiki page that contains all:
- Main concepts
- Decision process
- Benchmarks
- API designs
- How you can help!
Please see attached: https://code.djangoproject.com/wiki/new_meta_api
F
Hi Curtis,
Of course! I will be happy to open a document with my performance tuning
experience. Said this, I am very far away from being a "performance master"
and I am still looking at places where my code can improve. It would be
nice if it was a wiki page, where everyone can share and correc
Hi Josh,
Thanks to your advice.
On Saturday, July 5, 2014 12:11:07 PM UTC+2, Josh Smeaton wrote:
>
> Excellent work, well done. I have a couple of questions/ideas though.
>
> 1. The use of bit flags irks me. Would it be possible just to use numerous
> keyword arguments to the new get_fields ?
>
Can I ask as a favour to future works that you record all the performance
tuning approaches you use?
Many of these will be obvious to seasoned Python programmers, but some of
them won't be, and it would be nice to have a catalogue of "things to look
out for" to apply to critical paths in Django.
Excellent work, well done. I have a couple of questions/ideas though.
1. The use of bit flags irks me. Would it be possible just to use numerous
keyword arguments to the new get_fields ?
2. Since you've reduced the API to effectively two functions (get_fields,
get_field), is it still necessary t
RE work in progress code
The main functions to optimize are get_new_fields, get_new_field, they are
found
here:
https://github.com/PirosB3/django/blob/a92c37f0cad6bdd7a3b24ef235c81a7dab6bee72/django/db/models/options.py
On Sunday, June 22, 2014 11:49:05 AM UTC+2, Daniel Pyrathon wrote:
>
> Sur
Sure!
https://github.com/PirosB3/django/compare/soc2014_meta_refactor_performance?expand=1
This contains the following:
- Recently merged unit test suite for model/options
- New API implementation: get_new_fields, get_new_field.
- Implementation of recently merged unit test suite with new API
Is there somewhere I can look at your work in progress code?
On 21 June 2014 19:57, Daniel Pyrathon wrote:
> Hi All,
>
> This week I have done the following
>
> *- Openend PR and merged Options (_meta) unittests*
> https://github.com/django/django/pull/2823
> This is a working test suite of mod
Hi All,
This week I have done the following
*- Openend PR and merged Options (_meta) unittests*
https://github.com/django/django/pull/2823
This is a working test suite of model/options.py file. Is is currently
testing the current Options implementation.
*- Re-implemented test-suite in the new A
I like this simplification a lot. I hope you can make it work.
Just check that you don't "overload" fields, by storing in field objects
information that doesn't belong there.
--
Aymeric.
On 13 juin 2014, at 19:53, Daniel Pyrathon wrote:
> Hi All,
>
> This week's work was a follow-up of la
Hi All,
This week's work was a follow-up of last week's work, with some new
discoveries with regards to the new API:
*1) Improved the current _meta implementation of unittests*
I refactored the current meta unittest branch into a more compact version.
I also added test cases for Generic Foreign
Hi All,
Based on the work done last week, this week I have worked on the following:
*1) Covered the current _meta implementation of unittests*
The current Options is not covered by unit tests at all, I have created the
model_options test module containing one or more unit tests for each
endpoin
Hi All,
An update on my side, some interesting work has happened this week: me and
Russell have decided to start on the implementation early in order to
understand better the internals of Options. Currently I am working on the
following:
*Providing one single function: get_fields(types, opts,
Hi All,
Just to make you know, I have put up the current _meta API documentation
here:
http://162.219.6.191:8000/ref/models/meta.html?highlight=_meta
As always, feel free to ask questions.
Daniel
On Monday, May 26, 2014 1:26:27 AM UTC+2, Daniel Pyrathon wrote:
>
> Hi Josh,
>
> The meta API spec
Hi Josh,
The meta API specified in the docs
(https://github.com/PirosB3/django/blob/meta_documentation/docs/ref/models/meta.txt)
is the current API. I have documented this in order to understand more of
the current implementation and it will be good to show a comparison when a
new meta API wi
Hi Chris,
Oh sorry about that! big typo over there. Modifying the gist.
Thanks,
Daniel Pyrathon
On Saturday, May 24, 2014 7:44:15 AM UTC+2, Chris Beaven wrote:
>
> Hi Daniel,
>
> The proposal looks interesting - I've only skimmed it so far but one
> question: you mention User.get_model() severa
Hi Daniel,
Nice work putting that document together. Is the meta document you put
together the current API or is it the API you are proposing? If the latter,
a few suggestions (and if others disagree, please point that out):
- Remove all mention of caching. That should be an implementation deta
Hi Daniel,
The proposal looks interesting - I've only skimmed it so far but one
question: you mention User.get_model() several times -- do you mean
User.get_meta()?
On Saturday, May 24, 2014 7:05:02 AM UTC+12, Daniel Pyrathon wrote:
>
> Hi all,
>
> In the last days I have built a documentation
Hi all,
In the last days I have built a documentation of the current state of
Options. Based on feedback and prototyping I have thought of a potential
interface for _meta that can solve the issues currently present, such as
redundancy (in code and in caching systems). The interface has also bee
Best of luck!
On Tuesday, 20 May 2014 03:56:06 UTC+10, Daniel Pyrathon wrote:
>
> Hi All,
>
> Today I will be starting my weekly updates on my SoC project: refactoring
> Meta to a stable API. For anyone who missed out, you will be able to view
> it here:
> https://docs.google.com/document/d/1yp
40 matches
Mail list logo
