On 27 March 2018 at 10:56, Nick Coghlan <ncogh...@gmail.com> wrote: > ... Making it so that lambdas > can close over class attributes breaks that equivalence, and if we > were to use the cell based approach I suggest above, the seams would > be visible in the case where a lambda expression references an > attribute that gets rebound after class creation: > > >>> C.f() > 1 > >>> C.x = 2 > >>> C.f() # With a cell based approach, this wouldn't change > 1 >
Yes - but that would be the intention of the code beign written as in your example - class C: x = 1 f = staticmethod(lambda: print(x)) While, the classic behavior can be attained by doing: class C: x = 1 f = classmethod(lambda cls: print(cls.x)) And the behavior in both cases if one of no-surprises for me. For coders who don't have the mechanism of class creation in their mind, that could come as a surprise, but it is better than being inconsistent. TL;DR: +1 for your approach - I am just saying your perceived drawback is not one IMHO. > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/