Hi, I’m Nick and I don’t want to feel myself when I call obj._meta as if I am committing a mortal sin.
I thought that refactoring Meta objects and make it usable is a promising contribution for the community, because there are a lot of situation when accessing _meta attributes and methods can save a lot of developers time: you can find hundreds real-life examples on Stackoverflow.com where people use _meta, but make a remark that it’s private, not recommended to use in general and should be covered with unit tests (yeah, that’s great, but not when you had to cover framework’s code). It also may be useful for those who chose to encapsulate their business logic in a “fat” models instead of views (can't imagine such use case of meta right now) since I think it’s a really good way to architect Django’s apps. As for me, I’m currently using Django-nonrel and, for example, I had to survive without multi table inheritance, so I really need to know many information about model classes and instances that is available but like forbidden fruit. It’s time to change that! :) Many of those for whom the Django is made are think: if it is written in the documentation -- then it can and should be used. If not -- don't even touch this. That’s the first reason why documenting Meta is the most responsible task. Second is that documentation (and the api itself, of course) should warn the user against destructive use of the object's interior. So, I’m as non-native English speaker, may seem at first glance not the best candidate for this, but I will put a lot of effort to find the best person for review of what I will write and the Django’s docs writing style looks very laconic. I am a little scared to work under hood of Django, but more challenging -- is more interesting. Any help with this project would be greatly appreciated! *Brief plan:* 1. Learn what actually supposed to be opened. I mean we have a few options. We can make stable and expose the whole obj._meta; we can make stable obj._meta, document it as well, but point some things which are really necessary for developers to obj.meta since it’s sound more comfortable to use and bonus points for backwards compatibility if any issues will appear. 2. Have fun while exploring Django so deeply (Options class and other meta related code). 3. Clean up related classes. 4. Write some unit tests that supposed to be self-documented my point of view on how API should looks like consequently. Ask Russell Keith-Magee (as my mentor) for master class about how API actually should looks like. 5. Do what developers usually do. Write brilliant clean code. 6. Cover all that with docs and examples. 7. Make sure that all is meets the requirements of Django standards. *A bit about myself:* Born and still in Ukraine. 21 years old. Last 5 years of my life I’m busy doing cool and not cool stuff using my programming skills (a couple of years in Django). In 2012 I've founded a Google Developer Group (GDG) community in my city, so sometimes we hold different events for developers. It would be really great if we could hold a Django thematic event with help of Django community! By the way, I am happy to help students in this mail-list by answering questions as a student that are previously participated in gsoc. -- 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 [email protected]. To post to this group, send email to [email protected]. 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/a74a02fe-ce13-413c-b10b-7bd0ebcb40b3%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
