On: Molten: A modern Python (3.6+) web framework

[duckerude]

This has a lot of edge cases.

Currently, `self` is a strong convention, but not more than that. You can write code like this:

  class Foo:
      def __init__(this, x, y=3):
          this.x = x
          this.y = y

Would a self-optional version of Python be able to recognize that it shouldn't make that method implicit? Breaking that code may or may not be acceptable, I don't know how common it is.

Would it still be possible to access methods on classes as if they're ordinary functions? e.g.

  >>> str.casefold('Foo')
  'foo'

It's occasionally useful for higher-order functions like map, or to call methods from different classes.

Would accessing methods like that return a special unbound method with an extra argument?

What's the behavior of functions that were defined elsewhere and attached to the class later?

  def double(n):
      return 2*n

  class MySpecialInt(int):
      double = double

  >>> MySpecialInt(10).double()
  20

Do they behave the old way? Do they behave the new way? Does it depend on their own parameter list?

How are decorators handled?

  def printme(func):
      def inner(*args, **kwargs):
          print(args, kwargs)
          return func(*args, **kwargs)
      return inner

  class Foo:
      @printme
      def bar(x, y):
          ...

Can `inner` access self? Can `bar/func` access self? `printme` certainly can't access self, because it doesn't exist yet when it runs.

It might be possible to make this change, but not without breaking compatibility. Argumentless super() adds behavior to something that used to throw a TypeError, which is much easier.

As a sidenote, I think super() is much more magical than string interpolation: f"foo: {foo!r}" can be rewritten to "foo: {!r}".format(foo), but rewriting super() requires looking at the surrounding code.