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.