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: Editing of __str__ and __repr__ docs
Type: Stage:
Components: Documentation Versions: Python 2.3
process
Status: closed Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: brett.cannon, donnc, rhettinger, staschuk
Priority: normal Keywords: patch

Created on 2003-04-25 22:25 by staschuk, last changed 2022-04-10 16:08 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
strreprdocs.patch staschuk, 2003-04-25 22:26
Messages (7)
msg43484 - (view) Author: Steven Taschuk (staschuk) Date: 2003-04-25 22:25
A recent thread in comp.lang.python [1] suggests that
there is some question whether the existing docs for
the __str__ and __repr__ methods is clear, and whether
what it says is good in the first place.

The patch shows proposed changes based on the
discussions in that thread.  The new text treats __repr__
as a programmer-centric stringification (with eval(repr(x))
== x as a possibility, rather than a principle), and __str__
as a more general-purpose stringification-as-appropriate-
to-the-object.

[1] http://groups.google.com/groups?th=24b817d49ec3a59b
msg43485 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2003-04-29 04:52
Logged In: YES 
user_id=80475

The patch looks technically correct.  It is wordy and I liked 
the original better, but clarity is more important.
msg43486 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2003-05-09 00:20
Logged In: YES 
user_id=357491

I agree with Raymond that it seems "wordy".  For instance, the first changed 
paragraph is basically just trying to say "__repr__ should return something 
that can be past to 'eval' to return return the same object.  If this is not 
possible then make its output useful to the programmer."  Don't need to go 
on about it needing to be a "valid Python expression" and such.
msg43487 - (view) Author: Donn Cave (donnc) Date: 2003-07-09 00:04
Logged In: YES 
user_id=42839

In __str__, I would replace the whole commentary paragraph 
with  "This string value is the result of converting the object 
data to string type, for use in applications that require a 
string and don't care about the original object per se."
msg43488 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2003-07-09 01:07
Logged In: YES 
user_id=80475

Consider taking this back to the newsgroup to tease out 
some wording that everyone finds more palatable.  The 
verbiage should be terse, factual, and general without being 
overly abstract or preachy.

The most recent suggestion (below) is not one I would 
approve. The circularity and indirectness make the docs 
unhelpful, hard to read, and uninformative.

Brett's suggestion is close to the mark.
msg43489 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2003-08-27 05:15
Logged In: YES 
user_id=80475

Can we close this patch or is a revision forthcoming?
msg43490 - (view) Author: Steven Taschuk (staschuk) Date: 2003-09-02 20:17
Logged In: YES 
user_id=666873

I'll close it; I have no revision coming.  Someone more motivated 
than I am can take the discussion to c.l.py if desired.
History
Date User Action Args
2022-04-10 16:08:20adminsetgithub: 38370
2003-04-25 22:25:31staschukcreate