On Wed, Oct 23, 2013 at 12:53:13AM -0700, Andrew Barnert wrote:
But type doesn't allow you to do most of what you can do in a class definition. This is like arguing that we don't need expression def because we already have types.FunctionType.
Given multi-line lambda, what could you do in a class definition that you couldn't do with type?
Write code that's somewhat readable and looks somewhat like Python?
No, that's not it. You can certainly write somewhat readable code that looks like Python using type. But definition, calls to type() look like Python code, because they *are* Python code. So I'm still curious as to what you can do in a class statement that couldn't be done in a call to type. The only thing I can think of is that class statement introduces a new scope, while type does not, so you can compute class attributes without affecting names in the enclosing scope: x = 42 y = 23 class Spam: x = "something" y = x.upper() + "!" assert x == 42 and y == 23 In the most general case, this would be rather tricky using type, without introducing extraneous variables. But I don't see this as a real problem for the suggestion. Nobody has come up with any major problems with this suggestion other than (1) it isn't strictly necessary, and (2) non-trivial function-expressions don't look very nice. I'm afraid I'm no different: although I can't find anything obviously wrong with the suggestion, nor can I develop much enthusiasm for it. I haven't used Ruby enough to really see the big deal for anonymous multi-line code blocks. I will say one thing: I do like the fact that this suggestion gives the functions a name, rather than making them anonymous. One disadvantage of lambda is that the lack of name makes it harder to debug them. That's not a problem in this case. So... +0 on named def expressions; -0 on anonymous def expressions; -1 on class expressions. -- Steven