[Python-ideas] Add kwargs to built-in function object

[Brandon Mintern]

> Just like lambdas were gotten rid of in favor of named inner functions
> (in part) for readability, it sounds like readability would be a
> strong argument for using namedtuple rather than some kind of an
> anonymous object.
>
> --
> Cheers,
> Leif

My only argument would be that classic usage of lambda had three main
purposes: (1) to create a function that is assigned to a variable, in
which case using def makes more sense, (2) to pass to functions like
map and filter, where the same functionality can be achieved with list
comprehensions, and (3) to pass to other functions. Getting rid of
lambda helps to eliminate the fallacy that is purpose 1, with list
comprehensions purpose 2 is less necessary, and purpose 3 is the only
real casualty. Even when you really do want to pass a lambda, it's not
very hard to say:

def f (x): return x*x

and then simply pass the f. Thus getting rid of lambda helps alleviate
a few issues while not hurting too badly.

With an anonymous object, however, I feel the case is a bit different.
You are not really using it to create an anonymous class, or even a
named tuple. You are instead using it to create an instance of object
which already has some fields defined. The same thing could be
accomplished with:

class anonobject:
    pass
a = anonobject()
a.one = 1
a.two = 2

But there is really no easier way that I can think of to do this on
the fly except to have already built a Record class as I previously
indicated. As long as this is the case, many users will be
implementing their own Record class with all the inefficiencies and
errors that come along with that. For example, my first iteration
looked like:

class Fields:
   """
   A class intended to provide a simple interface for creating objects
   with named fields. That is, instead of returning a tuple and indexing
   it or writing a unique class, you can simply do something like:
   a = Fields(x=1, y=2)
   a.x # 1
   a.y # 2
   """
   def __init__ (self, **kwargs):
       for name, value in kwargs.iteritems():
           self.__dict__[name] = value

Not horrible, but it still failed to utilize dict.update(), and the
original name was much less intuitive. Someone reading my code would
likely have to check out the Fields source to see what exactly I'm
doing.

Come to think of it, the change to object that I am suggesting could
even place the kwargs in __slots__ so that the instance it returns is
similar to that currently returned by object(), in that it is not
possible to add new fields.

All in all, though, I feel like such a change would actually *improve*
code readability in general, as we would be less likely to use a tuple
or a dict to hold what is truly an object. As soon as it becomes
apparent that our object is being used in more complicated ways, it
should be easy to write our own class with the same fields as our
original call to object and drop it in, adding a reasonable
constructor, methods, etc.