For taking values alternately from a series of iterables, there's two
primary functions:
builtin.zip
itertools.zip_longest
zip of course stops when the shortest iterable ends. zip_longest is
generally a useful substitute for when you don't want the zip behavior, but
it fills extra values in the b
Dear all: thank you for your replies and thoughts, most especially Steve
and Terry. I am more-or-less new to contributing to Python, so I wasn't
sure that the bug tracker was the best way to start -- I was looking for a
sanity check and received exactly what I wanted :) Thanks to the feedback
here,
ussion in favor
of it.
Thanks again to all for the replies.
Bill
On Mon, Nov 20, 2017 at 10:08 AM, Steven D'Aprano
wrote:
> Hi Bill,
>
> I don't have time to go through your email in detail and respond to
> every point you raise, but I'd like to respond to one point you ma
Nothing so bombastic this time. The heapq functions are basically all named
"heapsomething", and basically all take a "heap" for their first argument,
with supplementary args coming after. It's a textbook example of the
(hypothetical) Object Oriented Manifesto™ where defining a class increases
type
ultiple times. Last time was on this thread
> https://mail.python.org/pipermail/python-ideas/2016-October/043024.html.
>
> On Tue, Nov 21, 2017 at 3:13 AM, bunslow wrote:
>
>> Nothing so bombastic this time. The heapq functions are basically all
>> named "heapsomething&q
On Wed, Nov 22, 2017 at 10:52 PM, bunslow wrote:
> I'll just note the original proposal I made was specifically designed to
> be the minimum possible improvement, to avoid controversy (and e.g. a PEP).
>
> I agree that there are significant flaws and room for improvement in th
Something *should* be object oriented with the functions in question all
operate on the same data type, and in particular, those functions/verbs
*are only well defined for that type*. heapq.heappush(list-not-heap, item)
is perfectly valid code in the current interface, but doesn't make any
sense at
On Mon, Nov 27, 2017 at 4:36 PM, Paul Moore wrote:
> On 27 November 2017 at 21:59, Nick Timkovich
> wrote:
> > On Mon, Nov 27, 2017 at 8:17 PM, Brett Cannon wrote:
> >>
> >> But calling it "atrocious" and so bad that it needs to be fixed
> >> "immediately" as if it's a blight upon the stdlib is
I certainly didn't take away the right lesson! And lesson well learned,
hopefully.
On Tue, Nov 28, 2017 at 12:55 AM, Nathaniel Smith wrote:
> On Mon, Nov 27, 2017 at 7:22 PM, bunslow wrote:
> > My first submission to this list was predicated on what I'd read in PEPs
> --
