(original) (raw)
Yea, \*must\* probably should have been \*should (unless indicated by the method name)\*. I forgot about the many methods that don't. But the names of these methods, like \`split()\`, imply the types that they return.
Your example reminded me of the convention (outside python core) to name getters and setters so that they imply their returned type. Similarly for conversion methods like \`to\_\*()\`). But the name \`format\`, in my mind, implies that it only changes the \*contents\* of the str, rather than morphing its type.
The % example surprised me too, but it clicked for me when I realized % is a binary operator and not a method.
On Thu, May 18, 2017 at 7:25 AM, Random832 <random832@fastmail.com> wrote:
On Thu, May 18, 2017, at 01:14, Hobson Lane wrote:
\> Because \`.format()\` is a method on an instantiated \`str\` object in e and
\> so
\> must return the same type
That it \*must\* return the same type is overstating the matter. Split
returns a list (and, rather like %, the list is of unicode or str
objects depending on the argument). Join will return a unicode object if
any of the elements of the sequence are unicode. I was honestly
surprised though to see that % returns unicode when formatting a unicode
value, since my mental model of %s was more like {!s} - call str() on
whatever object is at the given position in the right-hand argument.
This kind of ad hoc implementation decision (format always returns str,
other methods can return unicode, ljust/rjust refuse to accept a
unicode character argument) is what Python 3 moved away from.
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/ hobsonlane%40gmail.com