Very interesting / exciting. I'm definitely +1 on this project - I definitely have some of the "break hard" projects that Russell is talking about and I'd love to have a more straightforward and sustainable way to do introspection.
Let me know how I can help. On Fri, Sep 23, 2011 at 10:47 PM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Fri, Sep 23, 2011 at 6:10 PM, sebastien piquemal <seb...@gmail.com> wrote: >>> So - it's one of those things that *should* be documented and >>> fomalized; it's just waiting on someone with the spare time to do the >>> job. >> >> Sounds good ! Any estimation on how big is the cleaning task ? I know >> documentation task can go forever :) > > About as long as this piece of string that I'm holding. Oh, wait - you > can't see the string? Let me hold it up for you... :-) > > Seriously -- I can't really answer this. It's not a completely trivial > task, but it's not complex on the order of "multi-db" or "no-sql > support" either. The first step really is an audit -- a rough cut at > documenting everything that is there at the moment. Once we have that, > we can look at how the existing API is being used, and evaluate the > cleanup opportunities. > > Once that's done, we'll be in a much better position to evaluation how > much work is involved. > >> And what about the extra features I suggested ? A more user-friendly >> way to get all -data- fields (including m2m, excluding pointers), an >> easy way to get the name of the pk field of the first parent. > ... >> Or did I miss some methods/properties from the _meta API ? > > Off the top of my head, I can't answer this. It's *possible* that > there might be some way to do this, but I'd need to go digging to work > out for sure, and I can't refer to the documentation to find out > easily :-) > > However, I wouldn't be at all surprised if it isn't possible. The > _meta API is mostly designed for Django's own internal needs, and > Django needs to make a very clear distinction between fields and > m2m's, forward and reverse fields, and so on; hence the distinctions > that exist in the current API. "Iterating over all fields" doesn't > make much sense from an internal perspective, because different types > of fields need to be handled differently. Similarly, the "hidden" _ptr > fields might not be important from a public visibility perspective, > but they're very important from an internal perspective. > > That said, just because Django doesn't have a use for the API doesn't > mean it wouldn't be useful. If you can propose a clean way to augment > the _meta API to provide this sort of capability, I don't see any > fundamental reason why it shoudn't be included. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- Justin Holmes Head Instructor, SlashRoot Collective SlashRoot: Coffee House and Tech Dojo 60 Main Street New Paltz, NY 12561 845.633.8330 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
