classification
Title: Sphinx glitch in library/functions
Type: Stage: resolved
Components: Documentation Versions: Python 3.2, Python 3.3, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: eric.araujo Nosy List: docs@python, eric.araujo, ezio.melotti, georg.brandl, python-dev, sandro.tosi, terry.reedy
Priority: normal Keywords: easy

Created on 2011-06-09 16:06 by eric.araujo, last changed 2012-05-07 21:43 by eric.araujo. This issue is now closed.

Messages (13)
msg137997 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-06-09 16:06
In the summary table at the top of library/functions, the links for frozenset and memoryview do not jump to the definition down in the same file, but link to stdtypes.
msg138006 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2011-06-09 16:26
This is not a Sphinx glitch: that's where these classes are defined.

(Plus, dependencies work the other way round.)
msg138086 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-06-10 15:45
memoryview and frozenset do have a small entry in library/functions, and the links at the top of the file are meant to jump to entries in the same file.
msg138089 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2011-06-10 15:53
Well, then a different way of linking to them must be used.
msg138090 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-06-10 15:56
Certainly.  I tried using `.memoryview` without success.  How would you do it?
msg138091 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2011-06-10 15:57
You can put an anchor and use :ref:.
msg138095 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-06-10 16:05
Sounds like the easiest solution that could work, thanks.  I’m on it.
msg138554 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2011-06-17 21:25
I agree that all table entries should link to the entry in the same file.

dict() and set() also jump to CH. 4, in addition to memoryview and frozenset. Others all work properly.

The entries for classes should generally have a link to their section in '4. Built-in Types'. All do other than these:

range() definitely needs a forward reference to 4.6 sequence types 

bool() lacks forward references; it could have one to 4.2 Bool ops and 4.11.9 Bool values

object() -- no where to go.

slice() only has a reference to the glossary; it has no entry in Ch.4. "Slice objects have read-only data attributes start, stop and step which merely return the argument values (or their default). They have no other explicit functionality" is slightly wrong since there is the .indices method.

type(n,b,d) has no forward references as there is no where to go exactly
msg143404 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2011-09-02 15:45
New changeset 7a05cb3beddf by Éric Araujo in branch '3.2':
Fix a few links in the table of built-in functions (#12298)
http://hg.python.org/cpython/rev/7a05cb3beddf

New changeset 58dd7addef3a by Éric Araujo in branch '3.2':
Add links from library/functions to other docs.
http://hg.python.org/cpython/rev/58dd7addef3a
msg143414 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-09-02 16:54
> I agree that all table entries should link to the entry in the same file.
This is fixed in 3.2 and 3.3, with a bit of reST kludgery.  I’ll backport to 2.7 if there is no negative feedback.

> range() definitely needs a forward reference to 4.6 sequence types 
> bool() lacks forward references; it could have one to 4.2 Bool ops and 4.11.9 Bool values
I have added links in a subsequent commit.

> object() -- no where to go.
> type(n,b,d) has no forward references as there is no where to go exactly
I think this deserves another report.

> slice() only has a reference to the glossary; it has no entry in Ch.4. "Slice objects have
> read-only data attributes start, stop and step which merely return the argument values (or
> their default). They have no other explicit functionality" is slightly wrong since there
> is the .indices method.
Ditto.
msg160170 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-05-07 21:32
Sandro ported to 2.7 in 07b3fc67bf45.  Thanks!

If I may make two remarks:

- Please duplicate commit messages from 3.2 and 2.7: it makes it easier to understand what a changeset is about without having to hunt.  (This does not apply to 3.3 as the changeset with the full commit message is a direct parent and thus easily found.)

- I’m not retired yet :)
msg160173 - (view) Author: Sandro Tosi (sandro.tosi) * (Python committer) Date: 2012-05-07 21:41
Oh sorry Éric, I completely oversaw there was an issue associated with the cset - i'll pay more attention next time!
msg160174 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-05-07 21:43
No problem, what counts is that our documentation and code get better for our users, not my ego :)
History
Date User Action Args
2012-05-07 21:43:10eric.araujosetmessages: + msg160174
2012-05-07 21:41:58sandro.tosisetmessages: + msg160173
2012-05-07 21:32:40eric.araujosetstatus: open -> closed

nosy: + sandro.tosi
messages: + msg160170

resolution: fixed
stage: needs patch -> resolved
2011-09-02 16:54:05eric.araujosetmessages: + msg143414
2011-09-02 15:45:01python-devsetnosy: + python-dev
messages: + msg143404
2011-07-21 05:28:54ezio.melottisetkeywords: + easy
stage: needs patch
2011-06-17 21:25:05terry.reedysetnosy: + terry.reedy
messages: + msg138554
2011-06-10 16:05:03eric.araujosetstatus: closed -> open
assignee: docs@python -> eric.araujo
messages: + msg138095
2011-06-10 15:57:41georg.brandlsetmessages: + msg138091
2011-06-10 15:56:53eric.araujosetmessages: + msg138090
2011-06-10 15:53:35georg.brandlsetmessages: + msg138089
2011-06-10 15:45:15eric.araujosetmessages: + msg138086
2011-06-09 16:26:40georg.brandlsetstatus: open -> closed
2011-06-09 16:26:07georg.brandlsetnosy: + georg.brandl
dependencies: - Fix referencing of built-in types (list, int, ...)
messages: + msg138006
2011-06-09 16:24:27ezio.melottisetdependencies: + Fix referencing of built-in types (list, int, ...)
2011-06-09 16:06:52eric.araujocreate