gh-60712: Include the "object" type in the lists of documented types #103036
Conversation
|
The original author was Martin Panter, @vadmium. I fixed the co-authorship note. |
There was a problem hiding this comment.
Standard reminder: You can directly apply all the suggestions you want in one go by going to Files changed -> Clicking Add to batch on each suggestion -> When done, clicking Commit
Thanks! Various further textual, syntactic and formatting fixes.
Misc/NEWS.d/next/Documentation/2023-03-28-22-24-45.gh-issue-60712.So5uad.rst
Outdated
Show resolved
Hide resolved
Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM>
Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM>
Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM>
Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM>
Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM>
'dictionaries' to 'dict' Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM>
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
furkanonder
changed the title
furkanonder
requested review from
terryjreedy,
CAM-Gerlach,
JelleZijlstra and
merwok
Co-authored-by: Éric <merwok@netwok.org>
There was a problem hiding this comment.
Thanks for the changes to the standard library docs and the additional test.
I recommend that several of the additions to the Language Reference should be removed. For the language reference, we are trying to be concise and focus on syntax and semantics of the language with less focus on the implementation details (which would be appropriate in the standard library docs)..
| @@ -1733,10 +1741,10 @@ Basic customization | |||
|
|
|||
| .. method:: object.__str__(self) | |||
There was a problem hiding this comment.
I thought we had a doc bug years ago where we came up with a convention to differentiate object.__str__ (actual method that exists in the object class), anyclass.__bases__ (method that exists on all class; explaining the data model) and someclass.__str__ (method you can define in your class to implement a protocol)
I guess we didn’t…
…tamodel.rst for improved clarity.
You are welcome. |
Co-authored-by: Éric <merwok@netwok.org>
| @@ -2043,10 +2044,10 @@ Basic customization | |||
|
|
|||
| .. method:: object.__str__(self) | |||
|
|
|||
| Called by :func:`str(object) <str>` and the built-in functions | |||
| :func:`format` and :func:`print` to compute the "informal" or nicely | |||
| Called by :func:`str(object) <str>`, the default :meth:`__format__` implementation, | |||
There was a problem hiding this comment.
Does this role (without class reference) create a proper link to the __format__ method doc?
There was a problem hiding this comment.
When you click on :meth:`__format__, it directs you to object.__format__(self, format_spec)
| :class:`tuples <tuple>`) or :term:`mappings <mapping>` (like | ||
| :class:`dictionaries <dict>`), | ||
| :term:`dictionaries <dictionary>`), |
There was a problem hiding this comment.
🤔 Hm… on the line before, we see a general term used (with a link to glossary) and a concrete example in parens (list and tuple links), then we have the general/glossary term mappings and should keep the specific type dict in parens to keep the intent of the text. On the other hand, if the glossary term for dictionaries is a better explanation than the dict type/function doc, and more specific than the term for mappings, the changed link could be an improvement.
Co-authored-by: Éric <merwok@netwok.org>
Co-authored-by: Éric <merwok@netwok.org>
Co-Authored-By: @vadmium