Your proposal certainly would lead to ambiguity in reading:<div><br></div><div>_ = myfunc</div><div>if _:_(_:_, ...)</div><div><br></div><div>The "if _:_" means:</div><div><br></div><div> if '_' evaluates to boolean true, call it</div>
<div><br></div><div>The second _:_ uses your new lambda construct. Could a compiler parse it? Probably. Can a human understand it? Maybe, with difficulty, but it would surely lead to hard-to-find errors.</div><div><br>
</div>
<div>On Sun, Aug 9, 2009 at 3:29 AM, ilya <span dir="ltr"><<a href="mailto:ilya.nikokoshev@gmail.com">ilya.nikokoshev@gmail.com</a>></span> wrote:</div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Thank you and everyone else for insightful posts detailing why my<br>
examples don't make a good argument for the syntax.<br>
<br>
Even though my original suggestion, similarly pep 312, wouldn't break<br>
any existing programs and would not lead to ambiguity in 'if _:', I<br>
rescind it.<br>
<br>
However, another reason for implicit lambdas is lazy evaluation. For<br>
example, in another thread people discuss "... except ... if/else"<br>
conditional statement --- one reason being control expressions<br>
evaluate lazily. A function call passing callables currently looks<br>
ugly and unreadable:<br>
<br>
lazy_cond(expr, lambda: expensive(5), lambda: factorial(10**5))<br>
<br>
and here 6 keystrokes of 'lambda' word *do* matter.<br>
<br>
Therefore I hope my unsuccessful proposal will encourage people to<br>
find something that works.<br>
<div><div></div><div class="h5"><br>
<br>
On Sat, Aug 8, 2009 at 4:21 AM, Steven D'Aprano<<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>> wrote:<br>
> On Fri, 7 Aug 2009 10:46:40 pm ilya wrote:<br>
>> I was thinking about a good syntax for implicit lambdas for a while<br>
>> and today I had this idea: make ``_:`` a shortcut for ``lambda<br>
>> _=None:``<br>
><br>
> [...]<br>
><br>
>> The rationale is that you only want to get rid of lambda keyword to<br>
>> create a *very* simple function, the one that will be called either<br>
>> without parameters or with only one parameter. For everything more<br>
>> complicated, you really should go and write the explicit function<br>
>> signature using lambda.<br>
><br>
> Why would you want to get rid of the lambda keyword? What's the benefit?<br>
><br>
> Is this about saving twelve keystrokes?<br>
><br>
> lambda _=None:<br>
> versus<br>
> _:<br>
><br>
> Just how often do you want, or need, to write such a lambda? It seems to<br>
> me that not only is it a special case you want to break the rules for,<br>
> which goes against the Zen, but it's an incredibly rare special case.<br>
><br>
> _ as an identifier already has three conventional meanings:<br>
><br>
> (1) In the interactive interpreter, _ is the value of the last<br>
> expression typed.<br>
><br>
> (2) It is commonly used to mean "I don't care about this value", e.g.<br>
><br>
> t = ("Fred Smith", "123 Fourth Street", "New York", "dog")<br>
> name, _, _, pet = t<br>
><br>
> (3) It is also often used in internationalization.<br>
><br>
> You want to give it the extra meaning "a default parameter name for<br>
> lambda when I can't be bothered typing even a single letter name".<br>
><br>
> Because _ is already a valid identifier, this will break code that does<br>
> this:<br>
><br>
> while _:<br>
> process()<br>
> _ = function()<br>
><br>
> if _:<br>
> print "something"<br>
><br>
><br>
> Not the best choice of names, but somebody, somewhere, is doing that,<br>
> and your suggestion will break their code.<br>
><br>
><br>
> Looking at the three examples you gave:<br>
><br>
> map( _: _ + 5, some_list)<br>
> register_callback( _: True)<br>
> def apply_transform(..., transform = _:_, ... ):<br>
><br>
> In the first case, I wouldn't use the short-cut form even if it were<br>
> available. I'd write a lambda that used a more meaningful name. In this<br>
> case, I'm expecting an int, so I would use n, or a float, so I'd use x.<br>
> I'd also avoid setting the pointless default:<br>
><br>
> map(lambda x: x+5, some_list)<br>
> vs<br>
> map(_: _+5, some_list)<br>
><br>
> Since your suggestion doesn't do precisely what I want, the only reason<br>
> I would have for using your construct is to save seven keystrokes.<br>
> Encouraging laziness on the behalf of the programmer is not a good<br>
> reason for special-casing rare cases.<br>
><br>
> Second case: register_callback( _: True)<br>
><br>
> I assume you're implying that the callback function must take a single<br>
> argument. In this example, using _ as the parameter name to the lambda<br>
> makes sense, because it is a "don't care" argument. But if the callback<br>
> function is documented as always being given a single argument, I would<br>
> want to know if it was being called without any arguments, so the<br>
> default value of None is inappropriate and I would avoid using it.<br>
><br>
> Third case: def apply_transform(..., transform = _:_, ... ):<br>
><br>
> I don't think I'd write a function called apply_transform() which made<br>
> the transformation function optional, let alone buried deep in the<br>
> middle of a whole lot of extra parameters. (I presume that's what<br>
> the "..."s are meant to imply.) But putting that aside, I see your<br>
> intention: a default do-nothing function which appears in a very long<br>
> parameter list. The problem is that instead of trying to shrink the<br>
> default value so you can fit all the parameters on a single line, you<br>
> should make such a complicated function signature more readable by<br>
> spreading it out:<br>
><br>
> def apply_transform(<br>
> obj,<br>
> start, end, # start (inc) and end (exc) positions to apply<br>
> another_arg, # does something very important I'm sure<br>
> x=0, y=1, z=2, # more very important arguments<br>
> transform=( # default null transformation<br>
> lambda obj=None: obj),<br>
> frotz=False, # if true, frotz the hymangirator with spangule<br>
> hymangirator=None,<br>
> spangule=None,<br>
> magic=12345, # this needs no documentation<br>
> namespace={},<br>
> flibbertigibbet=None,<br>
> _private_magic=[] # the caller shouldn't supply this<br>
> ):<br>
><br>
> (Even better is to avoid such complicated function signatures, but<br>
> sometimes that's not an option.)<br>
><br>
> So again I'd be very unlikely to use your suggested construct except out<br>
> of simple can't-be-bothered-to-type-a-dozen-letters laziness. Pandering<br>
> to that sort of laziness is probably not a good thing.<br>
><br>
> Fundamentally, this suggestion doesn't add expressability to the<br>
> language, or power. Laziness on it's own is not a good reason for<br>
> special casing rare cases. If it was a very common case, then *perhaps*<br>
> you would have an argument for special casing needless verbiage:<br>
> conciseness (up to a point) is a virtue in a language. That's partly<br>
> why we have lambdas in the first place, so we can write this:<br>
><br>
> reduce(lambda a,b: (a+b)/2.0, somelist)<br>
><br>
> instead of this:<br>
><br>
> def average(a, b):<br>
> return (a+b)/2.0<br>
> reduce(average, somelist)<br>
><br>
> But this isn't a common case, it's a rare case, and the case you're<br>
> hoping to replace is pretty concise already.<br>
><br>
><br>
><br>
> --<br>
> Steven D'Aprano<br>
> _______________________________________________<br>
> Python-ideas mailing list<br>
> <a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/mailman/listinfo/python-ideas</a><br>
><br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/mailman/listinfo/python-ideas</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Gerald Britton<br>
</div>