[Python-ideas] anonymous object support

[Herman Sheremetyev]

[adding python-ideas back to CC]

On Mon, Jul 25, 2011 at 5:40 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 25 July 2011 08:41, Herman Sheremetyev <herman at swebpage.com> wrote:
>>>
>>> class Dummy: pass
>>>
>>> It's not really worth including something this short in the stdlib:
>>>
>>> from somewhere import Dummy
>>>
>>> is actually longer!
>>
>> This doesn't actually help with the "create object as an expression"
>> requirement. Steven D'Arpano's message describes some implementation
>> details, and it would be nice if you didn't have to import it though I
>> could live with that as well.
>
> I'm not quite sure I follow. Are you insisting that you need to create
> an instance and then assign an instance attribute/method <b>in a
> single expression</b>, and have the resulting instance be the value of
> that expression?
>
> If so, then I don't really see what you gain apart from saving a line
> or two in your source code, and confusing your reader. But if you must
> do that, then Nick's suggestion of using the type builtin would
> probably do what you want. (I make no claims that it's particularly
> readable, but I'd say you gave up on that when you insisted on a
> one-line solution :-))
>
> To compare, we're talking about:
>
> d = Dummy()
> d.foo = lambda x: x
> expression_involving(d)
>
> vs
>
> expression_involving(Dummy(foo = lambda x:x))

You could do that if it seems reasonable or useful in that particular
case, but more often than not I think you'd do something like:

variable = Dummy(foo=lambda x: x)
expression_involving(variable)

Having one line of code that accomplishes a simple task (creating an
object and saving it in a variable) instead of having to write N lines
for each attribute makes for more readability not less IMO. You can
still break lines inside the parens and add each attribute on its own
line, but the indentation would at least clue the reader to the fact
that it's really a single operation. Having N lines, especially if N
is more than 2 or 3, is begging for the whole thing to be moved off
into a helper function.

And in tests this kind of operation happens all the time.

> Even using trivial examples like this, I find the first more readable
> (and I'd curse the writer if I had to maintain code like the second).
> If expression_involving() was anything more complex than a function
> call, or foo was more than the identity function, this would be
> utterly unreadable.
>
> Can you point at any real code that implements a class-making function
> such as you describe, and then uses it? I'd be curious to see any
> real-world examples to check if my intuition that such code is
> difficult to understand holds up.

https://github.com/has207/flexmock/blob/master/tests/flexmock_test.py

You can take a look at the tests starting at line 56 -- the flexmock()
function does exactly what I'm proposing when given keyword args.

> PS Feel free to quote any of this mail back on-list. I would have
> added the list back into my reply, on the assumption that you simply
> forgot to include the list, but didn't want to do so without your
> agreement...

It wasn't my message that took the list off the CC :)

Cheers,

-Herman