Ok :) Honestly, I don't have that much time, so I can't promise to look actively into that (but I guess that's no big deal). Of course, if Justin helps it sounds like a more reasonable task :) Anyways, I could perfectly start with the first step :
> a rough cut at documenting everything that is there at the moment. Which would allow me to have a better knowledge at what the API has to offer exactly, and therefore give me a clearer idea on how to implement those "gimme all the fields" functions. That's for the theory ! > If you can propose a clean way to augment the _meta API to provide this sort > of capability That's for the practice ! What would be an "unclean" way for you ? Are you talking about (a) the beauty of the API itself, or (b) its implementation ? Assuming (a) : from what I understood from your previous message, _meta API's fate is -one day- to be a public API that everybody could use in peace and harmony, right ? So with that in mind ... is it clean to have methods for public use and and methods for internal use in the same object ? -> I guess in that case the best would be to make private all methods for internal use, and public all methods for public API, but that's probably not realistic since that would require massive renamings. > That said, just because Django doesn't have a use for the API doesn't mean it > wouldn't be useful. >From my perspective (and Justin's) it would be very useful !!! And I am pretty sure we are not the only ones ! Cheers, Sébastien On Sep 24, 10:41 am, Justin Holmes <jus...@justinholmes.com> wrote: > 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 > > athttp://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.
