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
ar", which is potentially confusing. The traceback
will show that bar() is being called from some given file and line
number, but when that is inspected, there is no bar() there, only an
expression which contains the function call foo() (and possibly other
calls).
I'm only interested
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
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 proposal for you people. Perhaps thi
24 matches
Mail list logo
