The explicit passing of context through "self" gives python methods combinator-like properties. Because of this, you can copy and paste the method and run it outside of the context of the class:
The above will work in global context. This makes python code significantly more refactorable than other OO languages. For example C++:
class SomeClass {
int someMethod(int someVar) {
return this.x + someVar;
}
}
If you copy and paste the method outside of the class:
int someMethod(int someVar) {
return this.x + someVar;
}
It won't work.
The python way just allows the method to be easily refactored to operate on a generic type (caveat: you have to ignore typing which the python interpreter actually does). Given a self.x, any value for self will be valid so long as it contains an x. Python does this automatically and that is the main difference.
The main problem with OO is unfortunately still not resolved under either example. OO promotes context to follow logic around preventing the logic from being reused in other contexts. Ultimately, this is what's needed for the greatest modularity:
Surprised I had to scroll down this far to read this. Not just refactoring, also debugging. If there's a buggy method in a class somewhere, I can just copy the offending method into Jupyter, set self = a suitable instance of the class and start teasing apart what is going on line by line.
Why can't you just call the method on the instance directly? This is only useful for when a, is not quite the same type as the the class you're copying the method from.
Do you mean why not have the method be global in the first place? That's fine for simple pipelines, not ones that need to be flexible and have some kind of reusable interface. And I personally find it a bit annoying if you have to switch between class methods and global ones jumping in and out of the class to understand what's happening.
if the method is called "f" and it exists on "a" then you have access to "f" via "a.f()". It's redundant to call it via "f(a)".
If you're saying it's easier to edit "f" in the repl/notebook vs. on the class where it's defined, well that's a sort of a convenience factor, I wouldn't exactly call it a huge benefit overall as this is mostly a very
specific use case.
The main thing that's different about python OO is the method.
The explicit passing of context through "self" gives python methods combinator-like properties. Because of this, you can copy and paste the method and run it outside of the context of the class: The above will work in global context. This makes python code significantly more refactorable than other OO languages. For example C++: If you copy and paste the method outside of the class: It won't work.The python way just allows the method to be easily refactored to operate on a generic type (caveat: you have to ignore typing which the python interpreter actually does). Given a self.x, any value for self will be valid so long as it contains an x. Python does this automatically and that is the main difference.
The main problem with OO is unfortunately still not resolved under either example. OO promotes context to follow logic around preventing the logic from being reused in other contexts. Ultimately, this is what's needed for the greatest modularity:
And although you can write the above with OO, the style ultimately promotes practices that steers programmers away it.