[Python-ideas] string codes & substring equality

[Terry Reedy]

On 11/30/2013 6:48 PM, Guido van Rossum wrote:
>
> On Sat, Nov 30, 2013 at 3:42 PM, Andrew Barnert
> <abarnert at yahoo.com
> <mailto:abarnert at yahoo.com>> wrote:
>
>     On Nov 28, 2013, at 22:49, Greg Ewing
>     <greg.ewing at canterbury.ac.nz
>     <mailto:greg.ewing at canterbury.ac.nz>> wrote:
>
>>     spir wrote:
>>>     (But then, possibly, some would wonder why this new ord(s,i) is
>>>     not a string method ;-)

ord and chr are inverse functions. Would you have chr be an int method?
(Even if yes, history comes into play here as ints did not have methods 
until 2.2(?, or close to that).

>>     For the same reason that the existing ord() function isn't
>>     a string method, whatever that is!
>
>     http://docs.python.org/2/faq/design.html#why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list
>
>     The short version is: historical reasons, and no reason to change it
>     compelling enough to be worth the costs in backward compat,
>     bikeshedding, etc.
>
>
> That FAQ entry does not do the real motivation justice. While OO
> "purists" may argue about it, to me it's obvious that in quite a few
> cases the function spelling is more readable than the method spelling. I
> found it more readable 23 years ago, and I still find it more readable
> today. So it's not historical reasons to me, even if not everybody
> agrees (obviously :-).

Sometimes functions are more functional (pun intented) than methods. 
len(ob) checks that ob.__len__() returns an int or something that can be 
'interpreted' as such. reversed(itable) checks for itable.__reversed__ 
before using a default version.

-- 
Terry Jan Reedy