str(container) should call str(item), not repr(item)

8/7/2019 str(container) should call str(item), not repr(item)

1/6

pdfcrowd comcustomize free license

Python Documentation

PEP: 3140

Title: str(container) should call str(item), not repr(item)Version: 226bf9ef3c9e

Last-Modified: 2009 01 05 01:20:25 +0000 (Mon, 05 Jan 2009)

Author: Mustapha Elmekki

Discussions-To:

Status: Rejected

Type: Standards Track

Content-Type: text/plain

Created: 27 May 2008

Post-History: 28 May 2008

Abstract

This document discusses the advantages and disadvantages of the

current implementation of str(container). It also discusses thepros and cons of a different approach - to call str(item) insteadof repr(item).

Motivation

Currently str(container) calls repr on items. Arguments for it:
http://pdfcrowd.com/redirect/?url=http%3a%2f%2fwww.python.org%2fdev%2fpeps%2fpep-0009&id=in-110503224515-56eb3f7fhttp://pdfcrowd.com/http://pdfcrowd.com/customize/http://pdfcrowd.com/license-for-free/http://pdfcrowd.com/redirect/?url=http%3a%2f%2fhg.python.org%2fpeps%2ffile%2ftip%2fpep-3140.txt&id=in-110503224515-56eb3f7fmailto:[email protected]?subject=PEP%203140http://pdfcrowd.com/redirect/?url=http%3a%2f%2fwww.python.org%2fdev%2fpeps%2fpep-0009&id=in-110503224515-56eb3f7f


2/6


-- containers refuse to guess what the user wants to see onstr(container) - surroundings, delimiters, and so on

-- repr(item) usually displays type information - apostrophesaround strings, class names, etc.

Arguments against:-- it's illogical str() is expected to call __str__ if it exists,

not __repr__-- there is no standard way to print a container's content calling

items' __str__, that's inconvenient in cases where __str__ and__repr__ return different results

-- repr(item) sometimes do wrong things (hex-escapes non-ASCIIstrings, e.g.)

This PEP proposes to change how str(container) works. It isproposed to mimic how repr(container) works except one detail- call str on items instead of repr. This allows a user to choosewhat results she want to get - from item.__repr__ or item.__str__.

Current situation

Most container types (tuples, lists, dicts, sets, etc.) do notimplement __str__ method, so str(container) callscontainer.__repr__, and container.__repr__, once called, forgetsit is called from str and always calls repr on the container'sitems.

This behaviour has advantages and disadvantages. One advantage isthat most items are represented with type information - stringsare surrounded by apostrophes, instances may have both class nameand instance data:

>>> print([42, '42'])[42, '42']>>> print([Decimal('42'), datetime.now()])
http://pdfcrowd.com/http://pdfcrowd.com/customize/http://pdfcrowd.com/license-for-free/


3/6


4/6


print(repr(test))print([test])print(str([test]))

to print

STRREPR

[STR][STR]

where it actually prints

STRREPR[REPR][REPR]

Especially it is illogical to see that print in Python 2 uses strif it is called on what seems to be a tuple:

>>> print Decimal('42'), datetime.now()42 2008-05-27 20:16:22.534285

where on an actual tuple it prints

>>> print((Decimal('42'), datetime.now()))(Decimal("42"), datetime.datetime(2008, 5, 27, 20, 16, 27, 937911))

A different approach - call str(item)

For example, with numbers it is often only the value that peoplecare about.

>>> print Decimal('3')


5/6


3

But putting the value in a list forces users to read the typeinformation, exactly as if repr had been called for the benefit ofa machine:

>>> print [Decimal('3')][Decimal("3")]

After this change, the type information would not clutter the stroutput:

>>> print "%s".format([Decimal('3')])[3]>>> str([Decimal('3')]) # ==[3]

But it would still be available if desired:

>>> print "%r".format([Decimal('3')])[Decimal('3')]>>> repr([Decimal('3')]) # ==[Decimal('3')]

There is a number of strategies to fix the problem. The mostradical is to change __repr__ so it accepts a new parameter (flag)"called from str, so call str on items, not repr". Thedrawback of the proposal is that every __repr__ implementation

must be changed. Introspection could help a bit (inspect __repr__before calling if it accepts 2 or 3 parameters), but introspectiondoesn't work on classes written in C, like all built-in containers.

Less radical proposal is to implement __str__ methods for built-incontainer types. The obvious drawback is a duplication of effort- all those __str__ and __repr__ implementations are only differin one small detail - if they call str or repr on items.

The most conservative proposal is not to change str at all but


6/6

str(container) should call str(item), not repr(item)

Documents

Transcript of str(container) should call str(item), not repr(item)