I’d like a class hierarchy diagram for the core Django modules (conf; contrib; core; db; dispatch; forms; http; middleware; template; templatetags; test; urls; utils; and views). I feel like I’ve seen this before but I can’t now find it in the Django documentation, or anywhere else come to that.
Alternatively if anyone has a recipe for using, say, pyreverse to produce this diagram would you share it please ? I have tried using pyreverse and the django_extensions graph_models but I can’t work out how to point it at, for instance, django.db.models.
I don’t remember ever seeing anything like that in the django docs.
I don’t know about a recipe, but I just did a little playing around with pyreverse and managed to get diagrams of django.db.models by running pyreverse django.db.models. That generates a pair of .dot files (classes.dot and packages.dot by default) that can then be converted to a variety of graphic image formats using graphviz.
(Interesting to see, but I find the resultant graph created by dot to be too big to be of any use.)
If you’re having a specific issue getting this to work, then it might be helpful if you provided the details of what you’re trying and what the results are that you are getting.
Thank you. That does work for me. Looking back though my shell history the nearest I got was pyreverse db.models , not sure why I thought that was going to cut it but it seemed reasonable at the time.
Having now seen the output I agree the output (at least of django.db.models) is too large to be useful to comprehend. I will try it with some of the other top level packages, but perhaps reconsider whether there are better options.
Thanks for your help, I appreciate it.
Doing some more playing -
Being more focused on specific classes can help create diagrams that are more useful than just trying to render an entire module.
For example: pyreverse -c django.forms.models.ModelForm django produces a much more readable diagram. (Side note: I also prefer using the -Gsplines=ortho parameter on the dot command. I think it creates a much “neater” image.)
Thanks, that is certainly more readable both because of the specific classes and the use of the Gsplines option.
I also found using --only-classnames works better than me (although of course many people would want more information).
I also experimented with –max-depth but got an error when I did. If anyone has any ideas about that I’d be interested to hear.
One odd thing I don’t understand it that I’m getting some green text which is not associated with any of the classes (see below), needs investigation.
Thanks again for your help.
Briefly, the green label is the name of the variable in the target class containing the type of object pointing to it.
For example, in this diagram, the green label “iterator” near the center is identifying that the variable “iterator” in ModelChoiceField is an instance of ModelChoiceIterator.
1 Like
From what I can tell, the version of pylint on pypi doesn’t have a max-depth parameter. The docs you’re referencing are for version 4.0.0, while the version on pypi is 3.3.4.
See Add --max-depth option to control diagram complexity by Julfried · Pull Request #10077 · pylint-dev/pylint · GitHub
You’d have to install the version from github to have that feature available.
