Re: [Python-ideas] Proposal for Ruby-style anonymous block functions (that don't kill the indention)

On 2008/11/09, at 8:15 pm, Mike Meyer wrote:
Properties have already been fixed in Python 2.6+ as far as I'm concerned, but I don't think that should be a valid use of the @, even without my caveats, since it's mixing blocks around inside an expression. The expression should be terminated before the beginning of the block.
Mostly on grounds of TWOOTDI. I know people already consider "x = lambda:" to be poor style, so I want to ban bad style preemptively with @. Incidentally, does anyone know why for decorators, @lambda x: x def f(): pass is a syntax error? I guess people just don't want lambda based decorators, for whatever reason.
I think it would look better on four lines. Maybe I'm wrong, but that's my intuition.
Ah, to be honest, I hadn't thought it through and just assumed it was impossible to make it work, since there would be two things needing indent-dedent tokens in a row. Still, isn't it a little ugly? (And remember, this proposal is not about adding power to Python, just making things more readable.)
Agreed. I fully expect the BDFL to reject this proposal, but I still think it's interesting to consider as a "solution" to the insolvable problem of multiline anonymous functions.

I actually like the idea. Having an @ in a statement turns that statement grammatically into the start of a block construct. But I prefer the easier way of allowing lambda x: print x; return x*x kind of syntax (which may require brackets around the lambda to disambiguate the semicolons), and that doesn't look like it's going to make it any time soon. I also agree with not liking something like myfunc = @(args): ..., but I don't think the grammar should be complicated with more special cases than necessary. Leave this to the style guide. One major technical problem with this is that it would stop the python grammar from being LL1, and I think Guido wants to keep it like that. In fact, I'm not quite sure this grammar is still context free (but I think it still barely is...) Jan

Jan Kanis wrote:
One major technical problem with this is that it would stop the python grammar from being LL1
Not necessarily. You could just allow any expression-statement to be followed by a block, and sort out whether it makes sense later on. -- Greg

On 14/11/2008, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Hm, hadn't thought about it in that way. Doing so now, if we follow this train of thought to it's ultimate conclusion everything is LL1, just parse the file as a sequence of characters and sort out whether they make sense later on :) . Jan

Jan Kanis wrote:
You're right that this is a possible implementation strategy, but it doesn't mean that "everything is LL(1)". Being LL(1) or not is a property of the grammar, and it concerns the language that the *parser* accepts. The Python language itself is actually not LL(1). CPython gets away with using an LL(1) parser because the parser accepts a slightly different language that's a superset of Python, and *that* language is LL(1) (meaning that you can write down an LL(1) grammar for it). This is the strategy used by almost all practical language implementations, and usually the division of labour is arranged so that the parser does most of the hard work of weeding out invalid programs. In the case you suggest, you've gone to the extreme of making the parser do almost none of the work, and although the language the parser accepts is LL(1), it's a wildly different one from the language the system as a whole accepts. So when we talk somewhat loosely about a language such as Python being LL(1), what we mean is that there is a superset, which isn't *too* much bigger, that's LL(1), and we make our parser recognize that superset. -- Greg

I actually like the idea. Having an @ in a statement turns that statement grammatically into the start of a block construct. But I prefer the easier way of allowing lambda x: print x; return x*x kind of syntax (which may require brackets around the lambda to disambiguate the semicolons), and that doesn't look like it's going to make it any time soon. I also agree with not liking something like myfunc = @(args): ..., but I don't think the grammar should be complicated with more special cases than necessary. Leave this to the style guide. One major technical problem with this is that it would stop the python grammar from being LL1, and I think Guido wants to keep it like that. In fact, I'm not quite sure this grammar is still context free (but I think it still barely is...) Jan

Jan Kanis wrote:
One major technical problem with this is that it would stop the python grammar from being LL1
Not necessarily. You could just allow any expression-statement to be followed by a block, and sort out whether it makes sense later on. -- Greg

On 14/11/2008, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Hm, hadn't thought about it in that way. Doing so now, if we follow this train of thought to it's ultimate conclusion everything is LL1, just parse the file as a sequence of characters and sort out whether they make sense later on :) . Jan

Jan Kanis wrote:
You're right that this is a possible implementation strategy, but it doesn't mean that "everything is LL(1)". Being LL(1) or not is a property of the grammar, and it concerns the language that the *parser* accepts. The Python language itself is actually not LL(1). CPython gets away with using an LL(1) parser because the parser accepts a slightly different language that's a superset of Python, and *that* language is LL(1) (meaning that you can write down an LL(1) grammar for it). This is the strategy used by almost all practical language implementations, and usually the division of labour is arranged so that the parser does most of the hard work of weeding out invalid programs. In the case you suggest, you've gone to the extreme of making the parser do almost none of the work, and although the language the parser accepts is LL(1), it's a wildly different one from the language the system as a whole accepts. So when we talk somewhat loosely about a language such as Python being LL(1), what we mean is that there is a superset, which isn't *too* much bigger, that's LL(1), and we make our parser recognize that superset. -- Greg
participants (3)
-
Carl Johnson
-
Greg Ewing
-
Jan Kanis