Re: proposed syntax for multiline anony-functions (hopefully?)
Dan Stromberg drsali...@gmail.com: Please don't add multiline lambdas to Python. Agree. Multiline lambdas give rise (in a big way) to the computer-language-equivalent of run-on sentences. Lambdas are perfect in Scheme because they are idiomatic in it. They carry a visual meaning and flow nicely with the parentheses and the indentation. Multiline lambdas would look out of place in Python. Also, they don't buy you anything functionality-wise or expressivity-wise. Lambdas are visually absolutely horrible in Java (which doesn't need them) and C++ (which is in dire need of them). However, it would appear lambdas are all in the rage among programming languages, and I could think of far worse fads (XML, shudder). So it may be that Python will eventually have to give in to multiline lambdas because of the marketing pressure. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: proposed syntax for multiline anony-functions (hopefully?)
Travis Griggs wrote: I do not like the python lambda. For two reasons. One: In a language that sought to be approachable by simple people (i.e. non computer science graduates who would use it in addition to their scientific/education background), I can’t believe they threw in a 6 character phonetic description of a greek character to imply “fragment of code expression to be executed in a removed context”. Show a subset of keyword.kwlist to a non-comp-sci guy and tell me if when they see the ‘lambda’ betwixt the others, they don’t stop and think “huh, one of these is not like the others”. Ha :-) The reason lambda is called lambda is that a Lisp fan added it, way back in the early days of Python, and Guido didn't notice until it was added. In functional programming circles, lambda comes from the lambda calculus, a branch of pure mathematics. But I'm not concerned about the name lambda. It's no more jargon than closure, coroutine, continuation, class [hmmm, what's with all the C words?] or comprehension. And besides, now as an English speaker, you get to feel the tiniest glimpse of what it is like to be a non-English speaking programmer forced to use these mysterious keywords `if`, `return`, `while`, `raise` and similar. Personally, I don’t think the desire to use lines as statement boundaries (something I like a lot) and at the same time to tersely pack multiple statements into a deferred code fragment, are reconcilable. And I don’t think there’s critical mass desire for them. So this subject will continue to resurface regularly. Agreed! -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: proposed syntax for multiline anony-functions (hopefully?)
On Aug 21, 2014, at 12:55 AM, icefap...@gmail.com wrote:
Hi, just wanting to do a shot in the dark,but maybe this syntax is Pythonic
(in a we-are-all-grown-ups fashion, ahem)enough to get its way into the
language
this is what yours truly thinks: don't we all know that : means the next
token must be an indent (mostly)? and doesn't the ( and its alikes, [ and }
begin an space-insensitive lexing context? so all we need is having an
space-sensitivity-stack and the corresponding ( counting stack and this
way we could match opening and closing () and pop the
space-sensitivity-stack whenever the ( counting stack gets a 0 at the top:
snip
Those more pythonista than me have weighed in on the particulars. I’ll offer
some more general thoughts.
While I dwell in the land of pythonistas, I’m a an expat from the Island of
Smalltalk. I live happily in Pythonville and will probably never return to the
shrinking island, I do miss Smalltalk’s block closures. I don’t miss them *too*
much, because things like comprehensions as well as the large library of
functional like modules, covers many of the use cases. But I do miss their
simple elegance.
I do not like the python lambda. For two reasons.
One: In a language that sought to be approachable by simple people (i.e. non
computer science graduates who would use it in addition to their
scientific/education background), I can’t believe they threw in a 6 character
phonetic description of a greek character to imply “fragment of code expression
to be executed in a removed context”. Show a subset of keyword.kwlist to a
non-comp-sci guy and tell me if when they see the ‘lambda’ betwixt the others,
they don’t stop and think “huh, one of these is not like the others”.
Two: The reason that this subject circles regularity, because they used a
keyword, it can only be used as a literal creator for a single line expression.
So we keep coming back to “how can we do multiple expressions with a
lambda/closure”.
For the unaware, the Smaltalk syntax for a literal block closure was a pair of
[ ]. First of all, I liked that the characters actually looked like a “block”
with the corners. I liked that it did not use parentheses. Parentheses are
pretty loaded already, and it helped the brain pick out the differences
instantly. I don’t like the OP’s proposal because I don’t think (def()) is
distinct from normal grouping () statements. And I liked how terse they are.
Two characters and you had a block. They are *everywhere* in the library.
Compare that with how often you find ‘lambda’ in the python standard modules. I
used to joke about the irony, that no language did more with functional
closures than the all-objects-all-the-time Smalltalk, and that CLOS had a more
robust object model than Smalltalk.
To me, for a multiple-expression (multi line or not) literal closure syntax to
succeed, it must a) denote both the start and stop (not a leading keyword), b)
be extremely terse so that the cost of creating closures is reduced c) not be
confused with other common literal denotation so it can be quickly recognized
when reading close (so [ and { are out for example, because of lists and
dictionaries, and using would cause complete confusion because it’s hard at
a glance to differentiate from a comparison operand).
Personally, I don’t think the desire to use lines as statement boundaries
(something I like a lot) and at the same time to tersely pack multiple
statements into a deferred code fragment, are reconcilable. And I don’t think
there’s critical mass desire for them. So this subject will continue to
resurface regularly. But I thought I’d chime in with a “foreigners” perspective.
--
https://mail.python.org/mailman/listinfo/python-list
Re: proposed syntax for multiline anony-functions (hopefully?)
On Thu, Aug 21, 2014 at 12:55 AM, icefap...@gmail.com wrote: Hi, just wanting to do a shot in the dark,but maybe this syntax is Pythonic (in a we-are-all-grown-ups fashion, ahem)enough to get its way into the language this is what yours truly thinks: don't we all know that : means the next token must be an indent (mostly)? and doesn't the ( and its alikes, [ and } begin an space-insensitive lexing context? so all we need is having an space-sensitivity-stack and the corresponding ( counting stack and this way we could match opening and closing () and pop the space-sensitivity-stack whenever the ( counting stack gets a 0 at the top: -- https://mail.python.org/mailman/listinfo/python-list
Re: proposed syntax for multiline anony-functions (hopefully?)
On Thu, Aug 21, 2014 at 12:55 AM, icefap...@gmail.com wrote: Hi, just wanting to do a shot in the dark,but maybe this syntax is Pythonic (in a we-are-all-grown-ups fashion, ahem)enough to get its way into the language this is what yours truly thinks: don't we all know that : means the next token must be an indent (mostly)? and doesn't the ( and its alikes, [ and } begin an space-insensitive lexing context? so all we need is having an space-sensitivity-stack and the corresponding ( counting stack and this way we could match opening and closing () and pop the space-sensitivity-stack whenever the ( counting stack gets a 0 at the top: Please don't add multiline lambdas to Python. Multiline lambdas give rise (in a big way) to the computer-language-equivalent of run-on sentences. If anything, I'd suggest removing single-line lambdas. List comprehensions and generator expressions render single-line lambdas almost entirely redundant; they're too TMTOWTDI. http://en.wikipedia.org/wiki/Run-on_sentence http://en.wikipedia.org/wiki/There's_more_than_one_way_to_do_it -- https://mail.python.org/mailman/listinfo/python-list
proposed syntax for multiline anony-functions (hopefully?)
Hi, just wanting to do a shot in the dark,but maybe this syntax is Pythonic (in a we-are-all-grown-ups fashion, ahem)enough to get its way into the language this is what yours truly thinks: don't we all know that : means the next token must be an indent (mostly)? and doesn't the ( and its alikes, [ and } begin an space-insensitive lexing context? so all we need is having an space-sensitivity-stack and the corresponding ( counting stack and this way we could match opening and closing () and pop the space-sensitivity-stack whenever the ( counting stack gets a 0 at the top: def doFunc(func): return func() doFunc(def(): print( anon ) return gvr) #this ) will try to decrease the ( -matching stak's top, but this is a zero(there is no ( to be matchd in the current context) so this will pop the ( stack and also the space sensitivity stack till a non-zero value gets in top of (-matching stac -- https://mail.python.org/mailman/listinfo/python-list
Re: proposed syntax for multiline anony-functions (hopefully?)
Ah, here we go again! It's multi-line lambda season. Comes around as
regularly as duck-typing season, rabbit seasoning, baseball season,
and other Looney Tunes references. :)
On Thu, Aug 21, 2014 at 5:55 PM, icefap...@gmail.com wrote:
doFunc(def():
print( anon )
return gvr)
What I'm seeing here is that def(): introduces a suite which becomes
a function definition that's part of the current expression. That's
reasonable, but I don't like the close parens on the same line; even
if this syntax is allowed, I'd frown on it in style guides,
recommending the close parens go on the next line:
doFunc(def():
print( anon )
return gvr
)
But either way, the question you need to answer is: How is this better
than the regular syntax for named functions?
def tmp():
print( anon )
return gvr
doFunc(tmp)
The one use-case that I can think of is large expressions like dict
displays, but I'd like to see a serious example that actually needs
this. Here's a toy example:
tag_handler = {
span: lambda content: content,
div: lambda content: \n+content+\n,
p: lambda content: \n+content+\n,
br: lambda content: \n,
}
If you wanted to expand one of those to have statements in it, you'd
have to take it out-of-line and break the flow. But this is totally
contrived and not real-world; before this sort of feature gets into
the language, there really needs to be a concrete use-case. Since
there's nothing that actually cannot be done with an out-of-line
function, the criterion has to be doing this out-of-line is extremely
ugly or error-prone, which is a fairly high bar to reach. You'll need
something where anyone will immediately say Oh, that way is horribly
hard to read, but the new way makes it beautifully clean!.
Python is much more statement-oriented than some languages. In Pike, I
can have a function that's syntactically a single gigantic expression,
because it (occasionally!!) makes sense to do it that way; Python
doesn't really give that option. So while Pike has good justification
for an anonymous function syntax with full statement support, Python
doesn't really call for it as much. That's why Python's survived this
long with its lambda functions being so severely restricted :)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: proposed syntax for multiline anony-functions (hopefully?)
reasonable, but I don't like the close parens on the same line; even if this syntax is allowed, I'd frown on it in style guides, thanks, bu what exactly do you find unlikeable in this syntax? the ) is no new syntax, but simply a match for a previous (; and you can put it anywhere because the ( contents are space-insensitive: this would be a syntax error: a = def(): print(gvr) this too: a = def(): print(anon) but not this: a = (def(): print(no) ) neither this: a = (def(): print(d)) nor this: a = (def(): print( no ) ) yours truly would be glad to know your thoughts on this -- https://mail.python.org/mailman/listinfo/python-list
Re: proposed syntax for multiline anony-functions (hopefully?)
On Thu, Aug 21, 2014 at 6:59 PM, icefap...@gmail.com wrote: thanks, bu what exactly do you find unlikeable in this syntax? the ) is no new syntax, but simply a match for a previous (; and you can put it anywhere because the ( contents are space-insensitive: this would be a syntax error: a = def(): print(gvr) this too: a = def(): print(anon) but not this: a = (def(): print(no) ) neither this: a = (def(): print(d)) nor this: a = (def(): print( no ) ) yours truly would be glad to know your thoughts on this I think it's less readable if the close parens goes on the previous line. However, that's a question of style, more than syntax. I just think it'd look better with a clear unindent at the end of a block of statements which all stand alone. But that was a small side point. What matters is: How is this new syntax better than out-of-line function definition? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: proposed syntax for multiline anony-functions (hopefully?)
reasonable, but I don't like the close parens on the same line; even if this syntax is allowed, I'd frown on it in style guides, thanks, bu what exactly do you find unlikeable in this syntax? the ) is no new syntax, but simply a match for a previous (; and you can put it anywhere because the ( contents are space-insensitive: this would be a syntax error: a = def(): print(gvr) this too: a = def(): print(anon) but not this: a = (def(): print(no) ) neither this: a = (def(): print(d)) nor this: a = (def(): print( no ) ) we're all grown-ups, aren't we? if we wanted to mess the syntax up then ( alone would have let us do obscene things like: if (a == b): gvr() or a =(1, 2 5 ) and we also could fiddle with an instance's (or class's) intendedly private members (no pun) but did we ever do? yours truly would be glad to know your thoughts on this -- https://mail.python.org/mailman/listinfo/python-list
Re: proposed syntax for multiline anony-functions (hopefully?)
it is simply a matter of convenience: def a(): print( gvr ) func(a); or func( def(): print(gvr) ) it would be great if others could further share their opinions -- https://mail.python.org/mailman/listinfo/python-list
Re: proposed syntax for multiline anony-functions (hopefully?)
icefap...@gmail.com: it is simply a matter of convenience: def a(): print( gvr ) func(a); or func( def(): print(gvr) ) it would be great if others could further share their opinions In practice, your proposal would not make life easier for Python programmers. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: proposed syntax for multiline anony-functions (hopefully?)
tag_handler = {
span: lambda content: content,
div: lambda content: \n+content+\n,
p: lambda content: \n+content+\n,
br: lambda content: \n,
}
If you wanted to expand one of those to have statements in it, you'd
have to take it out-of-line and break the flow.
what 'bout, well , this?
tag_handler = {
span:
lambda content: content,
div:
lambda content:
\n+content+\n,
p:
lambda content: \n+content+\n,
br:
lambda content: \n,
}
yours truly is trying to convey the actual fact that python could already be
untidy; what has kept the language tidy so far is partly because moral
developers
(the syntax being another half)
yours truly will hence think the proposition won't be directly untidifying the
syntax -- much in the sense that not-caring-for-ws-in-{ won't.
--
https://mail.python.org/mailman/listinfo/python-list
Re: proposed syntax for multiline anony-functions (hopefully?)
On Thursday, August 21, 2014 2:27:08 AM UTC-7, Marko Rauhamaa wrote: In practice, your proposal would not make life easier for Python programmers. Marko neither did the lambda, yours truly supposes? -- https://mail.python.org/mailman/listinfo/python-list
Re: proposed syntax for multiline anony-functions (hopefully?)
On 8/21/2014 5:14 AM, icefap...@gmail.com wrote: it is simply a matter of convenience: def a(): print( gvr ) func(a); or func( def(): print(gvr) ) it would be great if others could further share their opinions I have, multiple time in previous threads. A bad idea. Unnecessary. Nearly useless. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: proposed syntax for multiline anony-functions (hopefully?)
On 21/08/2014 7:30 PM, icefap...@gmail.com wrote: On Thursday, August 21, 2014 2:27:08 AM UTC-7, Marko Rauhamaa wrote: In practice, your proposal would not make life easier for Python programmers. neither did the lambda, yours truly supposes? alex23 disagrees. alex23 finds the lambda extremely convenient for things like sort, filter etc where alex23 wants to provide a function. alex23 finds this to be very readable: odds_list = filter(lambda x: bool(x % 2), some_list) By comparison, alex23 finds this to be more cumbersome for little gain: def odds_only(x): return bool(x % 2) odds_list = filter(odds_only, some_list) alex23 finds most examples for multiline anonymous functions to be far more difficult to parse than the both restricted lambda form and the separate function approach: odds_list = filter((def(x): return bool(x % 2)), some_list) alex23 isn't even sure if that's the correct format for your proposed syntax, or whether `, some_list)` has to appear on a separate line, or even if the () around the anonymous function is even necessary (alex23 assumed it was from your description of the closing parenthesis popping the space-sensitivity-stack). -- https://mail.python.org/mailman/listinfo/python-list
