> Python grammar is not LL(1) in general; just look at set and dict literals. This is really no different than ":" after an expression being legal inside a dict literal (and how you know that it is a dict literal).
Yes it is[0]. LL(1) Grammars can still be recursive, they just can't change the parsing rules based on distant context.
> As far as less vs more common case - I think it's more important to optimize for obviousness and consistency
Yes, but having the "easiest" thing you do:
class Foo:
def bar():
pass
silently do a usually unwanted thing (create a staticmethod) instead of an obviously wrong thing (raise an error)
isn't obvious. It's building a footgun into the language.
The rest of your comment complains about inconsistencies of how python converts various callables to methods. This is a fairly valid and interesting complaint, but has nothing to do with syntax, it is solely a semantic complaint that would be solved by having class creation treat all attributes that are callables as functions. In fact, you could customize class creation yourself this way using __new__, no syntactic changes required.
> as software grows more complex, the uncommon cases become common enough that you have to deal them regularly
While this is true, I think you vastly overestimate how common these constructs are. Like, you're in the realm of "this doesn't appear on github" levels of uncommon.
Personally, again, I think "you can't use partial() to define methods" is a very good thing: if you're doing this, you're into weird metaprogramming land. Its not any harder to, for example, write out
class Foo:
def frob(self, x, y): ...
def frob_xyzzy(self): return self.frob(x=1, y=2)
def frob_whammo(self): return self.frob(x=3, y=4)
unless you're doing weird metaprogrammy magic and then, as someone who does a lot of weird metaprogrammy magic
1. You deserve what you get
2. You can invoke deeper magic to solve these problems
[0]: https://discuss.python.org/t/switch-pythons-parsing-tech-to-...