This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2010年06月14日 15:09 by eric.araujo, last changed 2022年04月11日 14:57 by admin. This issue is now closed.
| Messages (8) | |||
|---|---|---|---|
| msg107790 - (view) | Author: Éric Araujo (eric.araujo) * (Python committer) | Date: 2010年06月14日 15:09 | |
Following a discussion on IRC: <birkenfeld> I would even prefer having more of just `object` instead of :func:`object` or :class:`object` I think it would be feasible to write a reST role that would use inspect or pydoc to find the type. It would not violate "In the face of ambiguity, refuse the temptation to guess" if it only resolves `somebuiltin` and `some.fully.qualified.name`. Cons: People unfamiliar with reST might confuse ``code`` with `name`; interpreting the role may prove non-trivial (either requiring importing Python module to introspect them, or keeping a mapping of names→types in some file). Thoughts? |
|||
| msg107795 - (view) | Author: Georg Brandl (georg.brandl) * (Python committer) | Date: 2010年06月14日 15:56 | |
The type doesn't matter anyway, no need to find it by questionable means. |
|||
| msg108223 - (view) | Author: Benjamin Peterson (benjamin.peterson) * (Python committer) | Date: 2010年06月20日 04:29 | |
-1 I like how explicit it is now. |
|||
| msg108238 - (view) | Author: anatoly techtonik (techtonik) | Date: 2010年06月20日 16:40 | |
`someref` would be more convenient than :func:`someref` but in case of namespace conflict (for example, as a result of documentation merge it both :func:`someref` and :class:`someref` can appear) - it would be necessary to go through all the links in both sources and update ambiguous references to point to the right type. But perhaps the biggest problem would be to explain users what happens. Also in the case when you create new :class:`someref` and Sphinx detects conflict. |
|||
| msg164690 - (view) | Author: Éric Araujo (eric.araujo) * (Python committer) | Date: 2012年07月05日 18:49 | |
> for example, as a result of documentation merge it both > :func:`someref` and :class:`someref` can appear I think this would cause a warning from Sphinx, as all class/meth/func/mod/etc roles look up in the same namespace (what Georg said). Benjamin is -1 for explicitness I am -0 because of the ` vs. `` possible ambiguity—I prefer disabling the default role altogether Georg, are you still +1 or should we reject this? |
|||
| msg170695 - (view) | Author: Ezio Melotti (ezio.melotti) * (Python committer) | Date: 2012年09月19日 01:49 | |
I think I'm -1 on this, for the following reasons: * it's less explicit; * it gives you less control (I'm thinking e.g. at the () added by :func:/:meth: but not :class:, so that :func:`int` and :class:`int` are rendered in different ways); * even though this might have been OK if we used it from the beginning, now we are using specific roles everywhere, and changing them will either result in a mass update or in a mixed style -- none of which are desirable; * if the mass update is done and later on we change our mind, it's difficult to switch back from `...` to :role:`...`. Disabling `...` sounds OK to me (I don't think we have many left, if any). |
|||
| msg173936 - (view) | Author: Éric Araujo (eric.araujo) * (Python committer) | Date: 2012年10月27日 16:34 | |
Unless Georg would still like this, I retract the proposal. Ezio: > Disabling `...` sounds OK to me (I don't think we have many left, if any). I think some of them crept up in logging and unittest docs, but they are easy to find with Doc/tools/rst-lint.py |
|||
| msg173948 - (view) | Author: Georg Brandl (georg.brandl) * (Python committer) | Date: 2012年10月27日 17:32 | |
I'm not very attached to it, so I'm fine with closing. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022年04月11日 14:57:02 | admin | set | github: 53242 |
| 2012年10月27日 18:18:27 | eric.araujo | set | status: open -> closed resolution: rejected stage: resolved |
| 2012年10月27日 17:32:52 | georg.brandl | set | messages: + msg173948 |
| 2012年10月27日 16:34:31 | eric.araujo | set | messages: + msg173936 |
| 2012年09月19日 01:49:18 | ezio.melotti | set | messages: + msg170695 |
| 2012年07月05日 18:49:20 | eric.araujo | set | messages: + msg164690 |
| 2012年05月15日 07:03:11 | ezio.melotti | set | nosy:
+ ezio.melotti |
| 2010年06月20日 16:40:17 | techtonik | set | nosy:
+ techtonik messages: + msg108238 |
| 2010年06月20日 04:30:01 | benjamin.peterson | set | nosy:
+ benjamin.peterson messages: + msg108223 |
| 2010年06月14日 15:56:54 | georg.brandl | set | nosy:
+ georg.brandl messages: + msg107795 |
| 2010年06月14日 15:09:10 | eric.araujo | create | |