[Python-ideas] anonymous object support

[Guido van Rossum]

2011/8/6 Carl Matthew Johnson <cmjohnson.mailinglist at gmail.com>:
>
> On Aug 6, 2011, at 12:53 PM, Devin Jeanpierre wrote:
>
>> My favorite declarative-namedtuple hack is http://code.activestate.com/recipes/500261-named-tuples/#c16
>>
>> Devin
>
> For non-link followers:
>
> def _namedtuple(func):
>    return namedtuple(func.__name__, func.__code__.co_varnames)
>
> @_namedtuple
> def Point(x,y):
>    pass
>
> That is very clever, but it kind of illustrates my point about needing a new keyword. When you see "def" don't you naturally think, "OK, what comes out of this will be a function named Point." But what comes out of this is not a function. It's a namedtuple, which is quite different…

I'm not sure I find that much of an objection. There are plenty of
situations where decorators are used to seriously pervert the type of
the defined name. Plus, what's a function? A class can be called as
well. What's the difference?

> A similar case can be made about
>
> @sort_list_with_keyfunc(my_list)
> def result(item):
>        ...
>        return normalized_item
>
> It's a neat way of getting out of writing the keyfunc before the sort, but it's a bad practice because you're def-ing a sorted list, not a function.

In this specific case I agree it's just confusing. (The difference is
that 'Point' above still can be called with x and y arguments,
returning a Point object.)

> Also a Ruby-like each can be done through abuse of decorators
>
> @each(my_list)
> def squared_list(item):
>        return item ** 2
>
> Neat but it breaks the reader's expectations. (Also, a list comprehension is shorter.)

Not to mention faster.

The main reason why the argument against these doesn't provide an
argument against @_namedtuple is that they don't create a callable
thing at all.

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