[Python-ideas] string codes & substring equality

[Nick Coghlan]

On 1 December 2013 14:33, Andrew Barnert <abarnert at yahoo.com> wrote:
> On Nov 30, 2013, at 15:48, Guido van Rossum <guido at python.org> wrote:
> 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 :-).
>
> I kind of read it the other way around--making _too many_ things methods is
> the historical quirk, because at some point (probably after making str and
> tuple and so on into full types) you and the other core devs went a bit
> farther with the OO-style "everything should be a method if at all possible"
> than you would have earlier or later in history.
>
> But I may have been assuming too much. A lot of other "multi-paradigm"
> languages went through a phase like that and have a historical legacy, like
> C++'s ridiculous string class and JavaScript's excess of Array methods. But
> Python does seen to have ended up with a lot fewer quirky choices than those
> languages. Still, I think the various index/find/count/etc. methods didn't
> all need to be methods.

One of the other things to keep in mind is that many of the builtin
function vs method choices predated the iterator protocol. A few have
since been updated to work with it (list.sort -> sorted, list.reverse
-> reversed), but others live on as Sequence ABC methods rather than
as builtins or itertools.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia