Opened 5 years ago

Last modified 16 months ago

#15396 new Bug

full path to modules in documentation inconsistently referenced

Reported by: slinkp@… Owned by: nobody
Component: Documentation Version: master
Severity: Normal Keywords:
Cc: jpic Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


To enable GzipMiddleware, you have to add to your MIDDLEWARE_CLASSES:

... which you'd have to work out by guesswork or reading the source, as it's not
specified on either

There are probably others similarly undocumented, but I haven't audited them all.

Change History (11)

comment:1 Changed 5 years ago by russellm

  • Component changed from Uncategorized to Documentation
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

comment:2 Changed 5 years ago by lrekucki

  • Severity set to Normal
  • Type set to Bug

comment:3 Changed 5 years ago by jpic

  • Cc jpic added
  • Easy pickings unset
  • Version 1.2 deleted

The path is documented on

Also, the module is documented in ref/middleware.txt, but it's not rendered in

GZIP middleware

.. module:: django.middleware.gzip
   :synopsis: Middleware to serve gziped content for performance.

.. class:: GZipMiddleware

So i guess that would be a bug in the documentation renderer, not the documentation contents.

comment:4 Changed 4 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:5 Changed 4 years ago by claudep

The add_module_names directive in docs/ is currently set to False. If set to True, it would prepend the module path to the class. However, there are almost 200 module:: or currentmodule:: directives in the documentation, so I don't know if displaying the full path is always the desired effect.

comment:6 Changed 4 years ago by ptone

  • Summary changed from full path to GzipMiddleware undocumented to full path to modules in documentation inconsistently referenced
  • Version set to master

#19281 was a dupe for the more general sense, so I've updated the summary to be a bit more generic.

This has always something that has bugged me - and has been somewhere on my todo list since this tweet crossed my path: :
"Python Dev Pro-tip: Include the import statements in each example in your documentation. Your casual readers will thank you."

So there are two places to add this information:

As information or heading in the reference documentation - and in code listings.

comment:7 Changed 3 years ago by aaugustin

#19864 was another duplicate.

comment:8 Changed 3 years ago by davesque

From duplicate #19864, I had thought about Carl's suggestion that the heading should instead state the full resource path instead of just the resource name:

class django.template.response.TemplateResponse
instead of
class TemplateResponse

I wasn't sure if that would sometimes be too verbose. That's why I had suggested the alternative:

module: django.template.response
class TemplateResponse

However, I prefer Carl's suggestion if it doesn't disrupt the layout of the current docs too much.

comment:9 Changed 3 years ago by EvilDMP

I agree that simply turning on display of modules with add_module_names would be a rather scattershot approach. Module names are not always provided anyway.

I think that the best approach would be for code samples to include imports, or at least the first one of a batch of them.

Similarly, if an object's path is not clear from its reasonably immediate context, then it should be spelled out in full the first time it's introduced in its reference documentation.

If there's a list of objects all from the same module, the module can be mentioned once at the top of the list.

comment:10 Changed 3 years ago by denis_g@…

It would be very nice to have this option somehow available, but disabled by default if you think it's not good to enable it for all.

For instance, full resource path may be rendered with the display: none style, so people who need it may enable it with the simple CSS rule.

Or there may be some kind of JavaScript magic, which would display the full resource path on user click or hover, or whatever else.

comment:11 Changed 16 months ago by timgraham

One option to display the full module path is something like this:

  • docs/ref/models/expressions.txt

    diff --git a/docs/ref/models/expressions.txt b/docs/ref/models/expressions.txt
    index f74c4f2..d0b4a14 100644
    a b output value. 
    360360``ExpressionWrapper()`` expressions
    363 .. class:: ExpressionWrapper(expression, output_field)
     363.. class:: django.db.models.ExpressionWrapper(expression, output_field)
     364    :module:
    365366.. versionadded:: 1.8
Note: See TracTickets for help on using tickets.
Back to Top