generator expressions: performance anomaly?

[Steven Bethard]

Bengt Richter wrote:
> Which make me wonder what plans there are for providing a better
> mechanism than default arguments as a way of initializing local function
> variables. Nested def's to create a closure with initialized values is
> pretty crufty for that, IMO.

What about using a class?  Associating functions with data is pretty 
much what they're for...

> Maybe extending the default argument space
> with whatever comes after e.g. a triple star delimiter in the argument list,
> but which wouldn't be counted as part of the normal arguments? E.g.,
> 
>     def foo(x, y=123, *args, **kw, *** i=1, deftime=time.ctime()):
>         return x*y, kw.get('which_time')=='now' and time.ctime() or deftime

If what you want is to have i=1 and deftime=time.ctime() available 
within foo, you could do something like (untested):

class foo(object):
     def __init__(self):
         self.i = 1
         self.deftime = time.ctime()
     def __call__(self, x, y=123, *args, **kwds):
         return x*y, (kw.get('which_time') == 'now'
                      and time.ctime() or self.deftime)
foo = foo()

Or if you don't like 'foo = foo()', you could probably abuse the __new__ 
method (also untested):

class foo(object):
     i = 1
     deftime = time.ctime()
     def __new__(cls, x, y=123, *args, **kwds):
         return x*y, (kw.get('which_time') == 'now'
                      and time.ctime() or self.deftime)

I guess my point is that if you want attribute associated with the 
function, it's often easy enough to write a class instead...

Steve