[Python-ideas] anonymous object support

[Steven D'Aprano]

Herman Sheremetyev wrote:
> It is currently somewhat difficult/awkward to create arbitrary
> "anonymous" objects in Python. For example, to make some object that
> simply has a foo() method you have to declare a class that defines
> foo() and instantiate it:
[...]

I'm not sure that "anonymous" is the right word here. Normally when we 
talk about "anonymous", it is in reference to functions and classes, 
which have a name given them at creation time. In that sense, early all 
objects in Python are anonymous: few objects have a __name__ attribute.

It seems to me that the name, or lack thereof, of the object is 
irrelevant to what you propose. Essentially, you want a one-liner for 
the pattern:

class MyObject(object):
     pass

obj = MyObject()
obj.spam = "spam spam spam"


> So why do we need this? Primarily, this sort of thing is very common
> in tests where it is often useful to generate anonymous objects with
> default values. As a result, a number of libraries have risen to fill
> this need which is a pretty strong indicator that it is a useful
> pattern, and everyone using one of a dozen different libraries to
> accomplish the same basic task does not seem very Pythonic. I could
> also see this being quite useful in quick prototyping scenarios in
> order to avoid using dicts when an object is more suitable without
> requiring the overhead of defining a class.

It might be more convincing if you could give examples of those libraries.



> I'm curious if people on this list would be interested in seeing
> support for this added to the language, or if there are some good
> reasons I have overlooked for why this sort of change might be
> undesirable.

Against the idea, it's a very simple helper class that you can add to 
your library or application:

class MyObject(object):
     def __init__(self, **kwargs):
         self.__dict__.update(kwargs)


Three lines, and now you can use it as a one-liner any time you want it:

obj = MyObject(flag=True, count=1)

In favour of the idea of making it built-in, or at least in the standard 
library: if this pattern is as common as you say, perhaps there should 
be a standard solution for it, instead of a plethora of almost, but not 
quite identical versions. After all, that is one of the main reasons we 
have bool as a built-in.

Also in favour: the implementation given may be slightly *too* simple. 
It doesn't have a nice repr(). There's no validation of the keyword 
arguments (although I'm not entirely sure they need validating). The 
more code needed to make it "professional", the better the argument for 
doing it once, right, in the standard library.

I don't think this needs to be object itself. Doing so probably will 
cause backwards incompatibility issues -- I'm sure that there will be 
code out there that expects object(attr="spam") to fail. Better to make 
a new type.

+0.5 on a new type for this, not necessarily a built-in.
-1 on changing object to behave this way.


-- 
Steven