[kd0amg]

> Python's OOP is awkward with object.f() meaning something different from f(object), when really they ought to mean the same thing.

Why should they? Coming from other OO languages, I would expect `object.f()` to involve a vtable lookup, or something similar that effectively has `object` carrying around its own particular implementation of `f` (which might have been closed over some hidden internal state as well), and I'd expect `f(object)` to not do anything of the sort.

> In Pandas, you sometimes have a function with the same name as a method, which behave subtly different from each other.

This sounds more like a poorly designed library than any language-level awkwardness.

[ogogmad]

> Python's OOP is awkward with object.f() meaning something different from f(object), when really they ought to mean the same thing.

>> Why should they? Coming from other OO languages, I would expect `object.f()` to involve a vtable lookup

Low level details like that should not concern me. In which case, maybe `f(object)` should do a vtable lookup then; why not? The syntax `object.f()` and `f(object)` should be interchangeable in all situations.

[lmm]

> This sounds more like a poorly designed library than any language-level awkwardness.

Languages ought to disallow these things. E.g. I'm constantly baffled that many languages won't let you use symbols as normal method names, but are absolutely fine with you having two methods whose names differ only in case. (There's even academic research showing that case sensitivity is the biggest pitfall for beginners learning Python).