[Python-ideas] string codes & substring equality

[Andrew Barnert]

On Nov 30, 2013, at 21:03, Nick Coghlan <ncoghlan at gmail.com> wrote:

> 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.

Sure, that's the part of "historical reasons" that seems accurate. There are a few methods that would be functions if they were added today (e.g., because the iterator protocol didn't exist), and a few functions that might be methods (e.g., because some of the standard types weren't class-like). Many of them would be the same even if they were added today; it's only the handful of exceptions that people even think to ask about.

If you read the FAQ as saying that Python should be Java/Ruby-style pure OO (or that it should be Haskell-style pure functional), but isn't because of historical reasons, then it's unfair and incorrect. But I just read it as saying the exact balance of methods vs. functions might turn out slightly different.