[Python-Dev] Re: "groupby" iterator

[Paul Moore]

Guido van Rossum <guido at python.org> writes:

> [Greg Ewing]
>> We seem to be talking about two different things in this thread,
>> speed and readability. The nice thing about the "attrgetter.x"
>> etc. idea is that it has the potential to provide both at once.

Yes. Frankly, readability (anybody's flavour) is easy to handle - all
of the various suggestions can be implemented in user code, without
any real problem. While a standard library solution may be useful for
consistency across applications, it'll only get consistently used if
it gives some other significant benefit (ie, speed).

So speed is the crucial point here, with readability a poor second. 
But speed is very rarely *really* crucial, no matter what people might
think. So we need something that is fast and nice-looking, to avoid
the "attractive nuisance" of something slower, but more "obvious" or
"readable" (ie, lambda).

Personally, I find the name operator.attrgetter (with semantics as
currently implemented) ugly enough that I'll probably never use it (or
only rarely, where speed is crucial). It's definitely not "the one
obvious way" for me. But naming is highly personal, so that's not a
good argument by itself.

>> The nasty thing about it is that it smells a bit too much like a
>> clever trick. It's really abusing the syntax to make it mean
>> something different from what it usually means.

While it still uses the name "attrgetter", I agree. However, with the
name "extract", I like the look of it enough that I'd overlook the
syntax abuse. But Guido's suggestion of requiring a constructor call
would swing me back the other way again (actually, I'd cheat and do
extract = extract() once and be done with it, but I'd feel unclean and
avoid the construct because of this...)

All personal opinion again, of course.

> It is also somewhat weak in that it only addresses lambdas with one
> argument, and only allows a single reference to that argument in the
> resulting expression, and can't really be made to handle method calls
> without more gross notational hacks -- even though it *can* be made to
> handle arbitrary binary and unary operators.
>
> Yet, it captures 90% of the use cases quite well.

I think this is the key thing here. Lambda in its full form is very
flexible and wide ranging - but 90% of the time, this flexibility
isn't needed. And everything pays a cost for that flexibility, even
when it's not used.

Something that did that 90%, fast and efficiently, while leaving
lambda for the few remaining cases where its flexibility is needed
(possibly with an intent to deprecate it in the future) would probably
be the best option.

Paul.
-- 
This signature intentionally left blank