Kaz Kylheku enlightened us with:
> Which proposed lambda syntax is closest in this sense?
I was talking about different ways (your multi-line lambda vs. the
currently implemented one) of doing function decorators.
> Is it unusual to have a tougher time explaining X than Y to people
> who are lear
Duncan Booth wrote:
> Kaz Kylheku wrote:
>
> > Duncan Booth wrote:
> >> One big problem with this is that with the decorator the function has
> >> a name but with a lambda you have anonymous functions so your
> >> tracebacks are really going to suck.
> >
> > Is this an issue with this particular de
Terry Reedy wrote:
> So name it err_inner. Or _err.
Right. The C language approach to namespaces.
--
http://mail.python.org/mailman/listinfo/python-list
"Kaz Kylheku" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Let me make the observation that name of an inner function is, alone,
> insufficient to identify that function in a debugging scenario. If you
> have some inner function called I, defined within function F, you need
> to
Kaz Kylheku wrote:
> Duncan Booth wrote:
>> One big problem with this is that with the decorator the function has
>> a name but with a lambda you have anonymous functions so your
>> tracebacks are really going to suck.
>
> Is this an issue with this particular design that is addressed by
> other
Sybren Stuvel wrote:
> [EMAIL PROTECTED] enlightened us with:
> > this is how I think it should be done with multi-line lambdas:
> >
> > def arg_range(inf, sup, f):
> > return lambda(arg):
> > if inf <= arg <= sup:
> > return f(arg)
> > else:
> > raise ValueError
>
> This is g
Duncan Booth wrote:
> One big problem with this is that with the decorator the function has a
> name but with a lambda you have anonymous functions so your tracebacks are
> really going to suck.
Is this an issue with this particular design that is addressed by other
designs?
Are the existing one-
[EMAIL PROTECTED] enlightened us with:
> this is how I think it should be done with multi-line lambdas:
>
> def arg_range(inf, sup, f):
> return lambda(arg):
> if inf <= arg <= sup:
> return f(arg)
> else:
> raise ValueError
This is going to be fun to debug if anything goes w
[EMAIL PROTECTED] wrote:
> this is how I think it should be done with multi-line lambdas:
>
> def arg_range(inf, sup, f):
> return lambda(arg):
> if inf <= arg <= sup:
> return f(arg)
> else:
> raise ValueError
>
> and instead of
> @arg_range(5, 17)
> def f(arg):
> return
this is how I think it should be done with multi-line lambdas:
def arg_range(inf, sup, f):
return lambda(arg):
if inf <= arg <= sup:
return f(arg)
else:
raise ValueError
and instead of
@arg_range(5, 17)
def f(arg):
return arg*2
you do:
f = arg_range(5, 17, lambda(arg)):
Antoon Pardon wrote:
> Could you give me an example. Suppose I have the following:
>
> def arg_range(inf, sup):
>
> def check(f):
>
> def call(arg):
> if inf <= arg <= sup:
> return f(arg)
> else:
> raise ValueError
>
> return call
>
> return check
def arg_r
Kaz Kylheku wrote:
> Kaz Kylheku wrote:
> > But suppose that the expression and the multi-line lambda body are
> > reordered? That is to say, the expression is written normally, and the
> > mlambda expressions in it serve as /markers/ indicating that body
> > material follows. This results in the
Op 2006-05-10, [EMAIL PROTECTED] schreef <[EMAIL PROTECTED]>:
> multi-line lambdas, had it been added to python a long time ago, would
> had reduced a lot of complexity in the language.
> for example - with multi-line lambdas - decorators are unneccesary.
I don't like the words neccesary or unnecc
[EMAIL PROTECTED] enlightened us with:
> multi-line lambdas, had it been added to python a long time ago,
> would had reduced a lot of complexity in the language. for example
> - with multi-line lambdas - decorators are unneccesary.
I love decorators.
> just give the multi-line lambda as an argu
multi-line lambdas, had it been added to python a long time ago, would
had reduced a lot of complexity in the language.
for example - with multi-line lambdas - decorators are unneccesary.
just give the multi-line lambda as an argument to a function - no need
for special syntax..
the alternative dec
Kaz Kylheku enlightened us with:
> In the case of if/elif/else, they have to be placed behind the
> closest suite that follows the expression in the syntax of the
> statement:
>
> if lambda(x)(4) < 0:
> print "a"
> lambda:
> return x + 1
> elif y = 4:
> print "b"
> else:
>
DH wrote:
> Kaz Kylheku wrote:
> > I've been reading the recent cross-posted flamewar, and read Guido's
> > article where he posits that embedding multi-line lambdas in
> > expressions is an unsolvable puzzle.
>
> To say that multi-line lambda is an unsolvable problem is completely
> absurd.
Note
Kaz Kylheku wrote:
> I've been reading the recent cross-posted flamewar, and read Guido's
> article where he posits that embedding multi-line lambdas in
> expressions is an unsolvable puzzle.
To say that multi-line lambda is an unsolvable problem is completely
absurd. Furthermore it has already b
Kaz Kylheku wrote:
> But suppose that the expression and the multi-line lambda body are
> reordered? That is to say, the expression is written normally, and the
> mlambda expressions in it serve as /markers/ indicating that body
> material follows. This results in the most Python-like solution.
Un
Op 2006-05-09, Scott David Daniels schreef <[EMAIL PROTECTED]>:
> Kaz Kylheku wrote:
>> I've been reading the recent cross-posted flamewar, and read Guido's
>> article where he posits that embedding multi-line lambdas in
>> expressions is an unsolvable puzzle.
>>
>> So for the last 15 minutes I ap
Kaz Kylheku enlightened us with:
> I've been reading the recent cross-posted flamewar, and read Guido's
> article where he posits that embedding multi-line lambdas in
> expressions is an unsolvable puzzle.
> [...]
> a = lambda(x, y), lambda(s, t), lambda(u, w): u + w
> statement1
> statem
Kaz Kylheku wrote:
> But suppose that the expression and the multi-line lambda body are
> reordered? That is to say, the expression is written normally, and the
> mlambda expressions in it serve as /markers/ indicating that body
> material follows. This results in the most Python-like solution.
I
Kaz Kylheku wrote:
> I've been reading the recent cross-posted flamewar, and read Guido's
> article where he posits that embedding multi-line lambdas in
> expressions is an unsolvable puzzle.
>
> So for the last 15 minutes I applied myself to this problem and come up
> with this off-the-wall propo
23 matches
Mail list logo
