homepage

In a great number of files, the ``code`` markup is used instead of the :data: role, which would create a link to the appropriate definition.
Unless someone objects, I would like to change all of them.

Links are good ;-).

+1

I would like to help out with this, as there seems to be a lot of work that needs to be done.
I guess I'm a little unsure about what you mean by ``code`` instead of :data:. Is ``code`` generic? Like in Doc/tutorials/classes.rst I see a lot of things similar to ``eval()``. Are you saying that dhould be changed to :data:eval()?

Nope, ``...`` can be used for generic pieces of code, whereas e.g. :data:`sys.stdout` indicates that stdout is a "data" attribute of the sys module.
If you use :data:`...` and rebuild the doc (cd Doc/; make html), you will see that e.g. sys.stdout will be then a link to the sys.html page.

Is this more what was in mind for the bug?

I presume so. I believe ``x`` is meant for general code like ``for thing in group: print(thing)``. While Éric specifically mentioned the :data: role, I presume the same idea applies to :func: and possibly other link-generating roles.
Is there a statement role, so that "effect of the ``global`` statement, " could be changed to link to the global statement doc?
This seems like a great project for a beginning developer to contribute patches.
Georg, do you have any reason to not have markup become more specific?

For global there's :keyword:. Also note that :data: should be used for module-level variables (or constant) not for attributes of e.g. classes and instances.
If there are other ``...`` that can be fixed (even using something else like e.g. :func: or :meth:), they should be fixed as well, but apparently ``...`` was often misused instead of :data: (maybe :data: was a recent addition).

> I would like to help out with this, as there seems to be a lot of
> work that needs to be done.
Thanks! In my initial report, I was talking only about module-level names that are documented as code (``sys.path``) instead of module-level data (:data:`sys.path`); the point is that the latter form creates a link to the doc of the module-level name.
I wasn’t aware that some functions and keywords used code markup instead or link-creating markup, like you found out for eval and getattr. These should be fixed too.
Terry: You’re right, ``x`` is the most generic markup for inline code in reST. It is used for command lines, program options that are not Python’s options (see #9312), bits of Python code, etc.
Now, about the amount of work needed: Don’t waste hours looking for all of these in the docs! If you know basic shell commands, it’s easy to have *all* instances of ``sys.path`` changed to :data:`sys.path` in one go. The thing requiring human attention is first listing all of the misuses of ````, second reviewing the changes.

instead of*
An addition: in some cases, it may be on purpose that someone used ``somename`` instead of :func:`somename`, for example to avoid a ton of link in the doc of the somename function. For the most part however, I believe it was just unawareness (or maybe unavailability) of the :data: construct that explains its absence.
One last precision: markup like ``getattr(spam, ham)`` should stay untouched: it is a code snippet, not just a reference to the function.

``...`` should also be used for common names like True, False, None (no one needs links to their doc to see what they are), or, as Éric said, to avoid creating links for each occurrence of a name (one such example is the name of a module in the page that documents it).
I think that ``getattr(spam, ham)`` could be also written as :func:`getattr(spam, ham) <getattr>` in case you want to generate explicitly a link to getattr. However in most of the cases this is not necessary.

Changing ``x`` to :data:`x` adds 4 chars.
Changing ``x()`` to :func:`x` justs adds 2.
If I were to review, I would prefer that the additions not trigger cascading line rewraps.

After thinking about this, I think it may be easier for everyone if I just did the change. It’s just a list of boring grep-sed combos to run, and it’s easier if a core dev just does it instead of reviewing a long patch. Sorry if you invested time, Bryce.

No worries, I totally understand. I was working on it a little bit at a time, as life would allow. And being probably more thorough than I needed to be. Here is the patch of everything that I've accomplished. Hope this helps.

Thanks Bryce, I will start from your patch. (BTW, you used func instead of data for sys.stdout.)

It would be best to think about each of the new links individually rather than making blanket changes. 
The new links need to have relevance and add value to the topic; otherwise, they are just distractions from the more relevant links that had been placed there in a thoughtful manner.
For example, I don't think the docs are improved by turning every ``sys.stderr`` into a link. How does that help users or does it just make the docs harder to read and obscure the move useful links.

I agree.

Alright, I’ll propose piecemeal patches.
Georg, two questions:
1) In the tutorial, should classes with no target use ``MyClass`` or :class:`!MyClass`? 
2) Should file extensions use ``.py`` or :file:`.py`? We currently have both.

Basically, :class:`!Foo` has no advantage over ``Foo``. The no-linking syntax is really only there for completeness, but I would prefer the plainer and easier to read (in source) ``Foo``.
For files, :file: really only has an advantage if you do something with the information that it's a file (which we don't, currently), or if you use the special feature that you can embed variable parts with {}.

Inclined to reject this, given the general dislike of huge low-value patches.