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.

classification
Title: The docs mark staticmethod as a function
Type: behavior Stage: resolved
Components: Documentation Versions: Python 3.1, Python 3.2, Python 2.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: docs@python Nosy List: SilentGhost, cool-RR, docs@python, eric.araujo, georg.brandl, rhettinger
Priority: normal Keywords:

Created on 2011-01-12 12:59 by cool-RR, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (10)
msg126090 - (view) Author: Ram Rachum (cool-RR) * Date: 2011-01-12 12:59
The Python documentation uses :func:`staticmethod` to describe staticmethod, while staticmethod is a type.

I want to link to the Python documentation from my project's documentation using Intersphinx, and I wouldn't want to mislead my users by marking static method as a function.
msg126102 - (view) Author: SilentGhost (SilentGhost) * (Python triager) Date: 2011-01-12 14:58
So, is int, str, bool and enumerate. And many others. The preface on functions page (http://docs.python.org/dev/library/functions.html) says: 

"The Python interpreter has a number of functions and types built into it that are always available."

I would think it's clear enough.
msg126200 - (view) Author: Ram Rachum (cool-RR) * Date: 2011-01-13 21:37
But why? What's the reason for that? Why mislabel a type as a function?
msg126201 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-01-13 21:40
staticmethod being a type or int being a function is really a CPython implementation detail.  If the docs say something is a class, it behaves as a class, you can subclass it and everything, and the other VMs implement it as a class, why would you want to consider the detail that it’s really a C function?
msg126202 - (view) Author: Ram Rachum (cool-RR) * Date: 2011-01-13 21:47
I'm really confused by your comment.

"int being a function is really a CPython implementation detail"

I don't understand this. I should be able to do isinstance(x, int) in all implementations of Python, no? So `int` must be a class across all Python implementation, no?

"why would you want to consider the detail that it’s really a C function?"

I don't want to consider the detail that int is a C function, I thought that int is a class and expected it to be marked :class:`int` in the documentation.
msg126204 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-01-13 22:00
Okay, scratch the comment about int, it’s not been accurate for quite a number of years.  Going back to staticmethod, my point still applies: Follow what the docs say.

staticmethod is a type in CPython probably due to the way descriptors work; contextlib.closing is a class for simplicity and efficiency; both of these examples are irrelevant internal details, they’re marked up as functions, so you should treat them as functions.
msg126208 - (view) Author: Ram Rachum (cool-RR) * Date: 2011-01-13 22:10
So if int is officially a class, why not start doing :class:`int` instead of :func:`int`?

"they’re marked up as functions, so you should treat them as functions."

Here, I've treated staticmethod as a function:

    >>> assert isinstance(staticmethod, types.FunctionType)
    Traceback (most recent call last):
      File "<pyshell#1>", line 1, in <module>
        assert isinstance(staticmethod, types.FunctionType)
    AssertionError

I get an error.

So I understand that you are using Sphinx's :func: role in a liberal way; You consider it okay to use it to mark anything that is callable, regardless of whether it's a function or a class. Am I right?

This looks to me like an abuse of Sphinx notation. When I read documentation I don't want to be second-guessing the author's intentions. If someone writes :func:`whatever` I expect `whatever` to be a function and not a class.

Perhaps we need a :callable: role?
msg126209 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-01-13 22:14
I don’t have enough experience to make a judgment call here.  Raymond or Georg, can you?
msg126211 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2011-01-13 22:22
That's just the way we do our markup.
Sorry, but this is a total non-issue.
You're trying to create finer distinctions
than the markup needs to support.

Besides, the distinction between types,
objects, callables, functions, instances,
descriptors and whatnot are much less
black and white than you might imagine.
msg126213 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2011-01-13 22:29
Fully agreed.
History
Date User Action Args
2022-04-11 14:57:11adminsetgithub: 55102
2011-01-13 22:29:57georg.brandlsetnosy: georg.brandl, rhettinger, eric.araujo, SilentGhost, cool-RR, docs@python
messages: + msg126213
2011-01-13 22:22:38rhettingersetstatus: open -> closed
nosy: + rhettinger
messages: + msg126211

2011-01-13 22:14:34eric.araujosetnosy: + georg.brandl

messages: + msg126209
versions: + Python 3.1, Python 2.7, Python 3.2
2011-01-13 22:10:48cool-RRsetstatus: closed -> open

messages: + msg126208
2011-01-13 22:00:42eric.araujosetmessages: + msg126204
2011-01-13 21:47:44cool-RRsetmessages: + msg126202
2011-01-13 21:40:16eric.araujosetversions: - Python 2.6, Python 2.5, Python 3.1, Python 2.7, Python 3.2, Python 3.3
nosy: + eric.araujo

messages: + msg126201

stage: resolved
2011-01-13 21:37:49cool-RRsetnosy: SilentGhost, cool-RR, docs@python
messages: + msg126200
2011-01-12 19:13:19rhettingersetstatus: open -> closed
nosy: SilentGhost, cool-RR, docs@python
resolution: not a bug
2011-01-12 14:58:24SilentGhostsetnosy: + SilentGhost
messages: + msg126102
2011-01-12 12:59:46cool-RRcreate