[Python-ideas] anonymous object support

[Herman Sheremetyev]

On Mon, Jul 25, 2011 at 9:18 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 25 July 2011 10:46, Herman Sheremetyev <herman at swebpage.com> wrote:
>>> 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.
>
> Thanks. That code does look nice and clean, although it is once again
> using artificially simple attributes (although that's not surprising
> in test code).
>
> But I'm still puzzled as to what you're asking for. Clearly (I assume)
> you're not asking for flexmock to be added to the stdlib. So are you
> asking for something like flexmock - in which case, what are the use
> cases for it (that aren't use cases for flexmock itself)?

No, I'm not asking for flexmock to be added to stdlib :) I'm writing a
different library based on my experiences with porting flexmock that
has a much cleaner and more Pythonic API that I *might* propose to be
added at some point but it's not really at the stage where it's ready
for discussion.

To answer your question, the use cases are exactly the same as *some*
of the uses for flexmock. This is precisely why I've proposed it as I
really don't think we need things like flexmock to do this. Flexmock's
primary function is creating partial mocks, checking expectations, and
ensuring it cleans up after itself. The fact that it allows for
creation of objects on the fly is not really what it's for, though it
provides that functionality, like most of the other mocking libraries,
simply because it's missing and is such a common pattern in tests that
a testing library would not really be complete unless it provided it.

> Sorry if I'm being dense here. If others understand the request feel
> free to drop this conversation as I'm not sure I'm adding much that I
> haven't already said.
>
> From my point of view, I see 3 separate aspects:
>
> 1. Specialised functions like flexmock, which fill a particular niche,
> and which quite reasonably hide the complexity of creating "anonymous"
> objects behind a simple API. No problem here, these are clearly
> useful, but they don't need to go into the stdlib unless their
> particular focus warrants it.
>
> 2. A generic "create object with dynamically assigned attributes"
> function. I haven't seen any use cases for this which aren't rare
> enough that a multi-line answer, or Nick's type() workaround, aren't
> sufficient.

Test code == code :) It's more code than "actual" code in many cases,
so I don't know what defines these use cases as rare. Tests are a
pretty obvious place where this is useful but I don't think it's the
only place and being able to create objects in this manner would
improve readability in a number of places where small, throw-away
objects are used.

A multi-line solution first requires a user-defined class. And I feel
like we really shouldn't have to define a class just to create an
object that we throw away two lines later. Using type()'s current
totally unwieldy API to do such an extremely simple and common thing
is again not really a good answer IMO.

I proposed some changes that shouldn't break type()'s current API
while making it usable for this particular pattern in my other
message. It's not a big change and I'd be happy to implement it and
send in a patch if nobody has any strong objections.

Cheers,

-Herman