[skywhopper]

Yep, this was my point. I'm curious what makes Python seem so obviously clear to other people, but not to me. Maybe it's the OO approach. I had done a lot of Java, Smalltalk, and Ruby before I ever tried to approach Python. Maybe it's because Python's OO support feels (to me) bolted on compared to those other languages which are obviously OO from the bottom up, and I'm unwittingly trying to apply mental models I developed in those other languages to how I think about Python.

[xapata]

But Python is OO from the bottom up. Unlike Java, everything in Python is an object.

Perhaps your experience with objects in other languages has given you a different mental model for what an object is. I find Python objects to be more straightforward than in other languages, especially because classes are objects, too.

[skywhopper]

If it really is OO, then the global `len()` function and like explicitly declaring "self" in method declarations makes it _feel_ bolted on (to me). Why is `len()` special? I immediately question what other basic operations aren't methods, but global functions.

And as for method declaration, if you aren't satisfied with implicit self, I much prefer Go's choice of having you declare the self reference for methods before the method name, instead of in the argument spec list (which then doesn't match the calling list). Python's way makes it feel like the compiler writer couldn't be bothered to hide the OO implementation on the declaration side, but embraced it on the calling side.

Meh, I know these have been hashed over a thousand times here. Just some of the things that rub me the wrong way when I've tried to deal with Python.

[ubernostrum]

If it really is OO

Python is a multi-paradigm language in the sense that it does not explicitly force the programmer to write all code in a particular way. So, for example, Python does not forbid the existence of standalone functions, or the execution of functions without looking them up through a class of which they happen to be a member.

But given that it is inescapably true that every function call in Python is translated to a call of a method of an object, it's hard to argue that it isn't "really" OO.

[xapata]

You can find explanations for both those questions in the design FAQ.

The explicit self came from Modula-3. https://docs.python.org/2/faq/design.html#why-must-self-be-u...

The explanation for len is a little lacking. https://docs.python.org/2/faq/design.html#why-does-python-us...

Guido once explained further in an email to the mailing list. I've forgotten some of it, but the gist is that he didn't want anyone to accidentally create or override a .len() method to do something other than tell the number of elements in the container.

And... almost everything is a method. Even ``len(obj)`` is just sugar for ``obj.__len__()``.

[ubernostrum]

almost everything is a method

Not "almost". Just "everything is a method", in terms of function calls. Even user-defined standalone functions. Consider:

    def my_func(arg):
        return arg + 5

The following are equivalent, and show how things work:

    my_func(3)

and

    my_func.__call__(3)

and

    types.FunctionType.__call__(my_func, 3)

[xapata]

I'm not certain, but I think the C API can avoid that. I've learned to say "almost" because every time I say Python can't X, someone shows me it can.

[ubernostrum]

There are a few functions in the C API to let you call things, depending on the type of thing and set of arguments you feel like providing, and they rely on the Python API to handle the calling for you. I imagine if you really wanted to, and knew enough about the structure and expectations of the Python object you were working with, you could "manually" call without going through one of those C API functions, but I don't know that I'd recommend trying it...

[aprdm]

len is a method. it is just a shortcut for object.__len__()

so is str and other shortcuts