[Python-Dev] Re: [Python-checkins] python/dist/src/Python bltinmodule.c, 2.292.10.1, 2.292.10.2

Paul Moore pf_moore at yahoo.co.uk
Sun Oct 26 15:27:21 EST 2003


Alex Martelli <aleaxit at yahoo.com> writes:

> On Sunday 26 October 2003 05:21 pm, Paul Moore wrote:
>    ...
>> I *think* I see what you're getting at here, but I'm struggling to
>> follow in the absence of concrete use cases. As we're talking about
>
> Assuming the simplest definition, equivalent to:
>
> def loop(bound_method, it):
>     for item in it: bound_method(item)
>
> typical simple use cases might be, e.g.:

[...]

> and so on.

None of which are, to me, particularly convincing. Then again, while I
like a "declarative style" in some cases, I've got nothing against the
sort of "idiom-based" style in which short code patterns just "mean
something" as a whole, and aren't viewed as being comprised of their
individual parts (much like the standard C idiom for walking a linked
list).

> The gain of such tiny "accumulator functions" (consuming one or
> more iterators by just passing their items to some mutating-method
> and ignoring the latter's results) are essentially conceptual -- it's
> not a matter of saving a couple of lines at the point of use, nor of
> saving some "bananoseconds" if the accumulator functions are
> implemented in C, when compared to the coded-out loops.
>
> Rather, such functions would allow "more declarative style"
> presentation (of underlying functionality that remains imperative):
> expressions feel more "declarative", stylistically, to some, while
> spelling a few steps out feels more "imperative".  We've had this
> preference explained recently on this group, and others over in
> c.l.py are breaking over the champagne at the news of list.sorted
> for essentially the same motivation.

OK. I'd bow out here, as I don't feel the need to push the declarative
style that extra step. Let others champion the style.

> Absolutely.  It's not _my_ suggestion to have more accumulator
> functions -- it came up repeatedly on the threads started by Peter
> Norvig original proposal about accumulation, and Guido mentioned
> them in the 'product' thread I believe (where we also discussed
> 'any', 'all' etc, if I recall correctly).

I'm sorry - I'd got the impression that you were arguing the case. In
which case, I'd have to say that I'm not at all clear who it is who's
proposing anything here, or what specifically the proposals are. I
suspect the original intention is getting lost in generalities, and
it's time for those original posters to speak up and clarify exactly
what they want. Maybe a PEP is in order, to get back to the core of
the proposal.

>> With a bit of "real life" use, migration into the standard library
>> might be more of an obvious step.
>
> You could have said the same of itertools before 2.3, but I think
> it was a great decision to accept them into the standard library
> instead; 2.3 would be substantially poorer without them.

Agreed. I was very conscious of itertools when I made that statement.
But my gut feel is that in this case, there has been so much
discussion that the key concept has been obscured. A PEP, or some
prior art, would recapture that.

> With an even richer complement of iterator tools in itertools, and
> the new "generator expressions" to give us even more great ways to
> make iterators, I think a module of "iterator consumers", also known
> as accumulation functions, would be a good idea. Look at Peter
> Norvig's original ideas for some suggestions, for example.

In principle, I don't have a problem with that. Let's get concrete,
though, and see either a PEP or some code. Otherwise, the discussion
isn't really going anywhere.

And on that note, I really ought to bow out :-)

Paul.
-- 
This signature intentionally left blank




More information about the Python-Dev mailing list