Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #76715 > unrolled thread

proposed syntax for multiline anony-functions (hopefully?)

Back to article view | Back to comp.lang.python

Contents

  proposed syntax for multiline anony-functions (hopefully?) icefapper@gmail.com - 2014-08-21 00:55 -0700
    Re: proposed syntax for multiline anony-functions (hopefully?) Chris Angelico <rosuav@gmail.com> - 2014-08-21 18:18 +1000
      Re: proposed syntax for multiline anony-functions (hopefully?) icefapper@gmail.com - 2014-08-21 01:59 -0700
        Re: proposed syntax for multiline anony-functions (hopefully?) Chris Angelico <rosuav@gmail.com> - 2014-08-21 19:05 +1000
      Re: proposed syntax for multiline anony-functions (hopefully?) icefapper@gmail.com - 2014-08-21 02:06 -0700
      Re: proposed syntax for multiline anony-functions (hopefully?) icefapper@gmail.com - 2014-08-21 02:27 -0700
    Re: proposed syntax for multiline anony-functions (hopefully?) icefapper@gmail.com - 2014-08-21 02:14 -0700
      Re: proposed syntax for multiline anony-functions (hopefully?) Marko Rauhamaa <marko@pacujo.net> - 2014-08-21 12:27 +0300
        Re: proposed syntax for multiline anony-functions (hopefully?) icefapper@gmail.com - 2014-08-21 02:30 -0700
          Re: proposed syntax for multiline anony-functions (hopefully?) alex23 <wuwei23@gmail.com> - 2014-08-22 15:15 +1000
      Re: proposed syntax for multiline anony-functions (hopefully?) Terry Reedy <tjreedy@udel.edu> - 2014-08-21 06:07 -0400
    Re: proposed syntax for multiline anony-functions (hopefully?) Travis Griggs <travisgriggs@gmail.com> - 2014-08-22 13:05 -0700
      Re: proposed syntax for multiline anony-functions (hopefully?) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-23 19:20 +1000
    Re: proposed syntax for multiline anony-functions (hopefully?) Dan Stromberg <drsalists@gmail.com> - 2014-08-22 16:48 -0700
    Re: proposed syntax for multiline anony-functions (hopefully?) Dan Stromberg <drsalists@gmail.com> - 2014-08-22 16:58 -0700
      Re: proposed syntax for multiline anony-functions (hopefully?) Marko Rauhamaa <marko@pacujo.net> - 2014-08-23 10:37 +0300

#76715 — 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


 

[toc] | [next] | [standalone]

#76718

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,  <icefapper@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

[toc] | [prev] | [next] | [standalone]

#76722

> 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

[toc] | [prev] | [next] | [standalone]

#76723

On Thu, Aug 21, 2014 at 6:59 PM,  <icefapper@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

[toc] | [prev] | [next] | [standalone]

#76724

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

[toc] | [prev] | [next] | [standalone]

#76727

> 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.

[toc] | [prev] | [next] | [standalone]

#76725

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 

[toc] | [prev] | [next] | [standalone]

#76726

icefapper@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

[toc] | [prev] | [next] | [standalone]

#76728

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?

[toc] | [prev] | [next] | [standalone]

#76773

On 21/08/2014 7:30 PM, icefapper@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").

[toc] | [prev] | [next] | [standalone]

#76730

On 8/21/2014 5:14 AM, icefapper@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

[toc] | [prev] | [next] | [standalone]

#76817

On Aug 21, 2014, at 12:55 AM, icefapper@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.

[toc] | [prev] | [next] | [standalone]

#76856

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

[toc] | [prev] | [next] | [standalone]

#76833

On Thu, Aug 21, 2014 at 12:55 AM,  <icefapper@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:

[toc] | [prev] | [next] | [standalone]

#76834

On Thu, Aug 21, 2014 at 12:55 AM,  <icefapper@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

[toc] | [prev] | [next] | [standalone]

#76846

Dan Stromberg <drsalists@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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web