[Python-ideas] anonymous object support

[Guido van Rossum]

On Mon, Jul 25, 2011 at 7:58 PM, Herman Sheremetyev <herman at swebpage.com> wrote:
> On Tue, Jul 26, 2011 at 11:42 AM, Guido van Rossum <guido at python.org> wrote:
>> On Mon, Jul 25, 2011 at 7:30 PM, Herman Sheremetyev <herman at swebpage.com> wrote:
>>> On Tue, Jul 26, 2011 at 9:18 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> <snip>
>>>> There is absolutely zero reason to add additional complexity to the
>>>> language core or the standard library for such a niche (and
>>>> questionable) use case when a simple wrapper function around type can
>>>> do the job.
>>>
>>> As you yourself pointed out, the complexity is already there in the
>>> core language hiding in a single line of API description to the type()
>>> function. It's already there to be used, but provides very little
>>> documentation and an API that is sure to baffle anyone that comes
>>> across code that uses it.
>>>
>>> To reiterate, I am proposing improving the type() API to provide some
>>> reasonable defaults while retaining backwards compatibility.
>>
>> Can you summarize the proposal for those who didn't follow the thread
>> blow-by-blow? Your first message proposed keyword arguments to
>> object(), which can't fly because object() creates objects without a
>> __dict__. Now you suddenly seem to have switched to adding more
>> complexity to type(). But what exactly?
>
> So the initial solution with type() posted above was:
>
>    obj = type('Foo', (), dict(foo=(lambda x: x)))()
>
> Adding the necessary "self" to the lambda, using an empty name, and
> replacing dict() with {} makes it slightly easier to parse:
>
>    obj = type('', (), {'foo': lambda self, x: x})()

Oh, that is bad. A single class object costs many thousands of bytes
in overhead and contains lots of cycles so GC needs to come along to
clean it up. And all that to create a single tiny object?

> [here are the API changes I propose]
>
> Going an extra step and making it possible for the dictionary to be passed in as
> keyword arguments would make it even nicer:
>
>    obj = type('', (), foo=lambda self, x: x)()

Same problem.

> And going one final step to give those first two positional arguments
> default values (empty
> string and empty tuple? or "Anonymous" and empty tuple?) would make it
> even better:
>
>    obj = type(foo=lambda self, x: x)()

I recommend that you create a library module that implements this more
efficiently and then see how often you *really* use it.

>>> In other
>>> words, making an *existing* difficult-to-use API into an intuitive
>>> one.
>>>
>>> FWIW, I think the type() function is not really a great choice for
>>> making classes on the fly. But if that's what we have to use then
>>> let's at least make it a little more user-friendly.
>>
>> So you are proposing to make an undesirable API more user-friendly.
>> Isn't that creating an attractive nuisance?
>
> Well, I think it's not very intuitive that type() can be used as a
> class constructor.

There's a way of looking at that which makes it very logical, and
intuition is learned. (This is counter-intuitive, but true
nevertheless. :-)

> But it is what it is at this stage, so if I come
> across it in code or write it myself I'd rather it provided some
> reasonable defaults.

My expectation is that you'll rarely come across a use case where the
keyword arguments are actually useful.

Plus, creating new dynamic class objects willy-nilly is hugely inefficient.

-- 
--Guido van Rossum (python.org/~guido)