> > Honestly that sounds way too complex. In my ideal world, only functions > defined with 'def' are methods whose __get__ auto-binds the first argument > (unless @classmethod or @staticmethod is present), and do not get to "see" > the class scope. This is how you define methods after all. Lambdas used at > class scope do not get this benefit, and they see the class scope as just > another closure; ditto for comprehensions and genexprs. > > I don't think that the "is the call delayed" idea is the proper way to > distinguish the two cases here. IMO the key concept is "is it used to define > a method". I betcha if you see a lambda here it's because there's some > calculation going on whose result will be stored as a class variable.
Nevertheless, treating lambdas differently from "def functions" in this context alone can be complicated. Even if not the most intuitive thing on writing code, everywhere else lambda s can't even be distinguished from "regular functions" once created. And I have created a lot of "one line methods" as lambdas over the years. (that is a lot of code that would be broke with no reason). Even calling "type" with a couple "lambda" expressionsin the namespace parameter is something very useful, and might be crippled if lambda's can't be methods at all (although that is a different context, I don't think things should be changed at this point) But there are two different things about lambdas in class bodies: - enabling a lambda to "see" the outer class scope: that is ok, as it would just make things simpler, and won't break existing code, as this ability did not exist before. - preventing a lambda to become a method though its `__get__`: this breakes stuff. As it is not incompatible with a lambda that can "see" the class scope, I see no reason for doing that (code might not work if a lambda with cell classes pointing to the class body, but my feeling is that it would just work correctly if such cells are permitted to start with) js -><- _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/