On 01.06.2016 21:48, Michael Selik wrote:
On Wed, Jun 1, 2016 at 3:14 PM Sven R. Kunze <firstname.lastname@example.org mailto:email@example.com> wrote:
On 01.06.2016 18:24, Michael Selik wrote:
I don't see how that would be improved by a special syntax for the [RHS] to know the identifier it's being assigned to. Could you clarify that?
I was referring to the issue that fields don't know neither their containing form classes nor their form instances. In some circumstances, one need to do that in order to correctly work with the field (think of the prefix of the form which needs to be reflected in the field but there are more missing pieces of information). As mentioned to Steven, in this case the name does not suffices at all. So, I am not sure how to handle this right now. This might belong to a greater issue of referring back which currently needs to be handled manually in all cases.
I always find bi-directional has-a relationships to be troublesome. If it were necessary frequently, I'd expect the Form metaclass to loop over the declared_fields and set some .form attribute to the new_class. Django is way too big for me to grok from light reading, so I won't presume to understand the choices made there.
That would be a hand-made solution and would work quite efficiently in terms of productivity for Django projects.
Recently, I started a private side project where I would need that back-relationship as well. This time, it's about rigid body simulation where I would like to pick a point in body space of a body and always get the correct world space coordinates when accessing. Same thing, but also hand-made by myself and it requires special attention from time to time.
I don't say I have a nice, readable solution for this but it seems to me that *providing context* to Python objects would as much help as it helps Google to provide extremely accurate search results.