what is lambda used for in real code?

Alex Martelli aleaxit at yahoo.com
Sat Jan 1 05:01:26 EST 2005


Terry Reedy <tjreedy at udel.edu> wrote:

> "Adam DePrince" <adam at cognitcorp.com> wrote in message 
> news:1104531721.3724.18.camel at localhost.localdomain...
> > 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 create an anonymous type, module, or class,
> especially with an expression.  Number, sequences, and dicts have easily

new.module('<theta>') creates a module and can be used within an
expression.  Of course 'anonymous' is doubtful, i.e.:

>>> new.module('<theta>').__name__
'<theta>'

but then

>>> (lambda:23).__name__
'<lambda>'

So the parallel is there, roughly.  You can create old-style classes
similarly, with new.classobj, and new-style ones by calling type, which
is more analogous to, say, creating sets by calling set, decimal numbers
by calling decimal.Decimal, and so on.

So the creating isn't a big problem -- by analogy with other types it
should be done by calling some callable, either built-in or from the
library.  And, we do have new.function for that; problem is the code
object that you need to pass as the first argument... there's new.code,
too, but it wants a gazillion args, including a codestring that's not
nice to put together;-).  "Not for the faint of heart" as the docs say.

Contents of modules and classes are less problematic.  Well, new.module
should perhaps take an optional dict argument, like new.classobj or
calling type -- right now it's hard to create _and populate_ the module
within the same expression.  Not that I have any use case for this,
though.  And there's the rub...:

> printable values.  Functions, like classes and module do not*, so 
> definition names act as a standin and as a pointer to the source code that
> produced the object.  If functions are not special relative to classes and
> modules, which is the grouping they belong with, then we should get rid of
> lambda ;-)

Yes but... we DO have a few real use cases for functions, which we don't
really have for modules and classes, _and_ making the *contents* of a
function object is harder too...:-(


Alex



More information about the Python-list mailing list