@staticmethod
(although why you want this instead of just a module scope function is unclear). If you want this strange behavior, you should be explicit about it.
@staticmethod
(although why you want this instead of just a module scope function is unclear). If you want this strange behavior, you should be explicit about it.
If you want `def foo(a, b)` inside a class to be a static method, you need to define it as
class Foo:
@staticmethod
def foo(a, b):
...
Now `f = Foo(); f.foo(1, 2)` will work.However, you need to be explicit about this because it is much more common for this situation to arise because someone forgot a self somewhere than for it to have been intentional. Requiring @staticmethod serves to signal to humans that this odd behavior is intentional (but again I'd say that, stylistically, if you're using a staticmethod, just move it out of the class and into the module namespace, module namespaces in python don't bite).
IMO it would make sense for Python to look at `a, b` and assume you wanted a static method with two parameters. Instead it assumes you're using `a` instead of `self` and really wanted an instance method with one parameter.
Like I said: most of the time, a missing `self` is an error by the user, and so python requires explicit notification both to the language, and to other people, that you're doing what you mean to do, and not just making a mistake.
Not really. You end up implicitly injecting some value into local namespaces instead of having a function that takes an argument.
The implicitness of methods working differently than normal functions > the implicitness of classes passing a first argument to methods.
def __init__(self, x, y):
self.super(x, y)
would be the convention. There may be some infra issue with this (and in general, `super` has to be kind of magical no matter how you handle it). But yes, in general I can vibe with "super is too implicit".