I thought it might be useful to put the recent lambda threads into
perspective a bit. I was wondering what lambda gets used for in "real"
code, so I grepped my Python Lib directory. Here are some of the ones I
looked, classified by how I would rewrite them (if I could):
* Rewritable as def st
Steven Bethard <[EMAIL PROTECTED]> wrote:
> (2) lambda a: a.lower()
> My first thought here was to use str.lower instead of the lambda, but of
> course that doesn't work if 'a' is a unicode object:
Right, but string.lower works (after an 'import string'). More
generally, maybe it would be nice t
> So, those are my thoughts on how lambdas are "really" used. If others
> out there have real-life code that uses lambdas in interesting ways,
> feel free to share them here!
I use them in conjunction with metaclasses and properties:
def _s_item(self, item):
""" saw::active """
Alex Martelli wrote:
Steven Bethard <[EMAIL PROTECTED]> wrote:
(2) lambda a: a.lower()
My first thought here was to use str.lower instead of the lambda, but of
course that doesn't work if 'a' is a unicode object:
Right, but string.lower works (after an 'import string'). More
generally, maybe it w
Steven Bethard <[EMAIL PROTECTED]> wrote:
> >>(3) self.plural = lambda n: int(n != 1)
> >>Note that this is *almost* writable with def syntax. If only we could do:
> >> def self.plural(n):
> >> int(n != 1)
> >
> > Not sure about the context, but maybe we could use, at class-level:
>
Alex Martelli wrote:
Steven Bethard <[EMAIL PROTECTED]> wrote:
py> class C(object):
... def __init__(self):
... self.plural = lambda n: int(n != 1)
...
py> c = C()
py> c.__class__.plural(1)
Traceback (most recent call last):
File "", line 1, in ?
AttributeError: type object 'C' has no
On Fri, 2004-12-31 at 01:53, Steven Bethard wrote:
> I thought it might be useful to put the recent lambda threads into
> perspective a bit. I was wondering what lambda gets used for in "real"
> code, so I grepped my Python Lib directory. Here are some of the ones I
> looked, classified by how
Adam DePrince wrote:
Lets not forget the "real reason" for lambda ... the elegance of
orthogonality. Why treat functions differently than any other object?
We can operate on every other class without having to involve the
namespace, why should functions be any different?
Yup. I think in most o
Adam DePrince wrote:
In sort, we must preserve the ability to create an anonymous function
simply because we can do so for every other object type, and functions
are not special enough to permit this special case.
Your reasoning makes sense... lambda enables you to create a function as
part of an
Hans Nowak wrote:
Adam DePrince wrote:
In sort, we must preserve the ability to create an anonymous function
simply because we can do so for every other object type, and functions
are not special enough to permit this special case.
Your reasoning makes sense... lambda enables you to create a funct
Steven Bethard <[EMAIL PROTECTED]> wrote:
...
> > Your reasoning makes sense... lambda enables you to create a function as
> > part of an expression, just like other types can be part of an
> > expression. However, by that same reasoning, maybe classes aren't
> > special enough either to warr
Adam DePrince wrote:
>> So, those are my thoughts on how lambdas are "really" used. If others
>> out there have real-life code that uses lambdas in interesting ways,
>> feel free to share them here!
>>
>
> Lets not forget the "real reason" for lambda ...
I really hoped you would point out th
"Adam DePrince" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> In sort, we must preserve the ability to create an anonymous function
> simply because we can do so for every other object type, and functions
> are not special enough to permit this special case.
Please show me how to
On Fri, 31 Dec 2004 22:09:49 -0500, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Adam DePrince" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > In sort, we must preserve the ability to create an anonymous function
> > simply because we can do so for every other object type, and fu
In article <[EMAIL PROTECTED]>,
Adam DePrince <[EMAIL PROTECTED]> wrote:
>
>Unless internationalization was a concern, few people would write:
>
>THE_ANSWER_IS = "The answer is"
>print THE_ANSWER_IS, x
However, there's a moderately large (and growing!) set of people who
would argue that I18N is *
Terry Reedy <[EMAIL PROTECTED]> wrote:
> "Adam DePrince" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > In sort, we must preserve the ability to create an anonymous function
> > simply because we can do so for every other object type, and functions
> > are not special enough to
Diez B. Roggisch wrote:
> The doc string of _s_item contains a token the metaclass is aware of and
> creates a wrapper around _s_item. That works nice on methods, but I found
> that properties got bound to their functions _before_ the metaclass kicks
> in, so the property wasn't called in the wrap
In article <[EMAIL PROTECTED]>,
Adam DePrince <[EMAIL PROTECTED]> wrote:
> We can operate on every other class without having to involve the
> namespace, why should functions be any different?
def is a weird beast. It does more than just bind a lambda to a name,
it also alters the function so
> Why not improve your metaclass wrapping so it knows about properties and
> replaces them with properties containing wrapped functions?
Erg - never thought of that, actually - it was so fast to introduce the
lambda...
But after some tinkering with metaclasses, I think it can be done - I have
to
Adam DePrince wrote:
[...]
In sort, we must preserve the ability to create an anonymous function
simply because we can do so for every other object type, and functions
are not special enough to permit this special case.
And you'd create an anonymous type how, exactly?
regards
Steve
--
Steve Holden
Steve Holden <[EMAIL PROTECTED]> wrote:
> Adam DePrince wrote:
> [...]
> >
> > In sort, we must preserve the ability to create an anonymous function
> > simply because we can do so for every other object type, and functions
> > are not special enough to permit this special case.
> >
> And you'd
Alex Martelli wrote:
Steve Holden <[EMAIL PROTECTED]> wrote:
Adam DePrince wrote:
[...]
In sort, we must preserve the ability to create an anonymous function
simply because we can do so for every other object type, and functions
are not special enough to permit this special case.
And you'd create
Steve Holden <[EMAIL PROTECTED]> wrote:
...
> >>And you'd create an anonymous type how, exactly?
> >
> type('',(),{})
...
> Indeed. And then you'd insert all the methods as lambdas by
>
> We both know that the Python language framework has enough introspection
> capabilities to do
Steven Bethard wrote:
The only ones that make me a little nervous are examples like:
inspect.py: def formatargspec(args, varargs=None, varkw=None,
...
formatvarargs=lambda name: '*' + name,
formatvarkw=lambda name: '**' + name,
On Fri, 2004-12-31 at 17:36, Steven Bethard wrote:
> Adam DePrince wrote:
> > Lets not forget the "real reason" for lambda ... the elegance of
> > orthogonality. Why treat functions differently than any other object?
> >
> > We can operate on every other class without having to involve the
> >
On Fri, 2004-12-31 at 22:09, Terry Reedy wrote:
> "Adam DePrince" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > In sort, we must preserve the ability to create an anonymous function
> > simply because we can do so for every other object type, and functions
> > are not special e
On Sat, 2005-01-01 at 11:42, Steve Holden wrote:
> Adam DePrince wrote:
> [...]
> >
> > In sort, we must preserve the ability to create an anonymous function
> > simply because we can do so for every other object type, and functions
> > are not special enough to permit this special case.
> >
> An
I wrote:
* Functions I don't know how to rewrite
Some functions I looked at, I couldn't figure out a way to rewrite them
without introducing a new name or adding new statements.
[snip]
inspect.py: def formatargspec(args, varargs=None, varkw=None,
...
formatvara
Steven Bethard wrote:
> * Rewritable with existing functions
> Mainly these are examples of code that can benefit from using the
> functions available in the operator module, especially
> operator.itemgetter and operator.attrgetter (available in 2.4)
> ...
> * Rewritable with list comprehensions/g
Hi all,
BTW, Alex Martelli and me have created a PEP 312 some time ago (when the
debate of inline if was hot).
I wish lambdas will not be deprecated in Python but the key to that is
dropping the keyword (lambda). If anybody could think of a better syntax for
lambdas _with_ arguments, we could de
Roman Suzi wrote:
I wish lambdas will not be deprecated in Python but the key to that is
dropping the keyword (lambda). If anybody could think of a better syntax for
lambdas _with_ arguments, we could develop PEP 312 further.
Well, my vote is still with Ruby-style codeblock syntax, but as a
compro
Roman Suzi wrote:
I wish lambdas will not be deprecated in Python but the key to that is
dropping the keyword (lambda). If anybody could think of a better syntax for
lambdas _with_ arguments, we could develop PEP 312 further.
Some suggestions from recent lambda threads (I only considered the ones
On Mon, 03 Jan 2005 18:54:06 GMT, Steven Bethard <[EMAIL PROTECTED]> wrote:
>Roman Suzi wrote:
>> I wish lambdas will not be deprecated in Python but the key to that is
>> dropping the keyword (lambda). If anybody could think of a better syntax for
>> lambdas _with_ arguments, we could develop PEP
On Mon, 3 Jan 2005, Steven Bethard wrote:
> Roman Suzi wrote:
> > I wish lambdas will not be deprecated in Python but the key to that is
> > dropping the keyword (lambda). If anybody could think of a better syntax for
> > lambdas _with_ arguments, we could develop PEP 312 further.
>
> Some suggest
Bengt Richter wrote:
On Mon, 03 Jan 2005 18:54:06 GMT, Steven Bethard <[EMAIL PROTECTED]> wrote:
Roman Suzi wrote:
I wish lambdas will not be deprecated in Python but the key to that is
dropping the keyword (lambda). If anybody could think of a better syntax for
lambdas _with_ arguments, we could
Roman Suzi wrote:
On Mon, 3 Jan 2005, Steven Bethard wrote:
Roman Suzi wrote:
I wish lambdas will not be deprecated in Python but the key to that is
dropping the keyword (lambda). If anybody could think of a better syntax for
lambdas _with_ arguments, we could develop PEP 312 further.
Some suggest
On Tue, 4 Jan 2005, Steven Bethard wrote:
>Roman Suzi wrote:
>> On Mon, 3 Jan 2005, Steven Bethard wrote:
>>
>>
>>>Roman Suzi wrote:
>>>
I wish lambdas will not be deprecated in Python but the key to that is
dropping the keyword (lambda). If anybody could think of a better syntax for
l
Roman Suzi wrote:
Maybe this is too outlandish, but I see lambdas as a "quote" mechanism,
which presents a possibility to postpone (precisely control, delegate)
evaluation. That is, an ovehead for lambda must be much lower but at the
same time visible to the programmer:
d = a + (lambda x, y: x+ y)
On Tue, 4 Jan 2005, Michael Spencer wrote:
>Roman Suzi wrote:
>
>> Maybe this is too outlandish, but I see lambdas as a "quote" mechanism,
>> which presents a possibility to postpone (precisely control, delegate)
>> evaluation. That is, an ovehead for lambda must be much lower but at the
>> same t
On Tue, 04 Jan 2005 14:11:51 -0800, Michael Spencer <[EMAIL PROTECTED]> wrote:
[Hm, this didn't go out for some reason. I'll just send it now.]
>Roman Suzi wrote:
>
>> Maybe this is too outlandish, but I see lambdas as a "quote" mechanism,
>> which presents a possibility to postpone (precisely con
40 matches
Mail list logo
