On Apr 25, 2020, at 09:40, Christopher Barker wrote:
>
> - The main exception to this may be when one of them is infinite, but how
> common is that, really? Remember that when zip was first created (py2) it was
> a list builder, not an iterator, and Python itself was much less
>
Soni L. wrote:
> it'd be nice if it did the same regardless of args.
Sorry, but "it'd be nice" is not a real world use case.
> inspired by PEP 559: https://www.python.org/dev/peps/pep-0559/
That PEP was rejected. It's okay to use previously rejected proposals
for inspiration, but your proposal
On Sun, Apr 26, 2020 at 4:12 AM Kirill Balunov wrote:
>
> But you also can always make such a switch with functools.partial.
>
Yes, I mentioned a wrapper function already, but that's still less
clean than a simple import.
ChrisA
___
Python-ideas
On Sat, Apr 25, 2020 at 09:39:14AM -0700, Christopher Barker wrote:
[...]
> > File handling code ought to be resilient in the face of such meaningless
> > differences,
>
> sure. But what difference is "meaningless" depends on the use case. For
> instance, comments or blank lines in the middle of
On Sat, Apr 25, 2020, 1:50 PM Kirill Balunov
wrote:
> Python uses such an approach (separate functions) because there are real
> flaws in the mode switching approach? Or just historically?
>
Well, I think I'd say "philosophically." It's not an historical curiosity
like some of the pass-through
But you also can always make such a switch with functools.partial.
-gdg
On Sat, Apr 25, 2020 at 8:59 PM Chris Angelico wrote:
> On Sun, Apr 26, 2020 at 3:53 AM Kirill Balunov
> wrote:
> >
> >
> >
> > On Sat, Apr 25, 2020 at 8:11 PM David Mertz wrote:
> >>
> >> I have no objection to adding a
On Sun, Apr 26, 2020 at 3:53 AM Kirill Balunov wrote:
>
>
>
> On Sat, Apr 25, 2020 at 8:11 PM David Mertz wrote:
>>
>> I have no objection to adding a zip_strict() or zip_exact() to itertools. I
>> am used to the current behavior, and am apparently in minority in not
>> usually assuming common
On Sat, Apr 25, 2020 at 8:11 PM David Mertz wrote:
> I have no objection to adding a zip_strict() or zip_exact() to itertools.
> I am used to the current behavior, and am apparently in minority in not
> usually assuming common length iterators. Say +0 on a new function.
>
> But I'm definitely -1
On Fri, Apr 24, 2020 at 06:07:06PM -, Brandt Bucher wrote:
> 1. Likely the most common case, for me, is when I have some data and
> want to iterate over both it and a calculated pairing:
>
> >>> x = ["a", "b", "c", "d"]
> >>> y = iter_apply_some_transformation(x)
> >>> for a, b in zip(x,
I'm sure you can find examples of modes. For example open() obviously has a
string mode and binary mode which are importantly different. I myself use
Pandas a lot, and it is absolutely thick with modes (but is very unpythonic
in numerous ways). Even print() with sep and end options has a kind of
On Sat, Apr 25, 2020 at 10:11 AM David Mertz wrote:
> I have no objection to adding a zip_strict() or zip_exact() to itertools.
> I am used to the current behavior, and am apparently in minority in not
> usually assuming common length iterators. Say +0 on a new function.
>
I'd say I'm +0 also
I have no objection to adding a zip_strict() or zip_exact() to itertools. I
am used to the current behavior, and am apparently in minority in not
usually assuming common length iterators. Say +0 on a new function.
But I'm definitely -1 on adding a mode switch to the built-in. This is not
the way
On Sat, Apr 25, 2020 at 7:43 AM Steven D'Aprano wrote:
> I think that the "correct" (simplest, easiest, most obvious, most
> flexible) way is:
>
> with open('a.txt') as a, open('b.txt') as b, open('c.txt') as c:
> for lineA, lineB, lineC in zip_longest(a, b, c, fillvalue=''):
>
On Sat, Apr 25, 2020 at 10:41 AM Steven D'Aprano
wrote:
> On Thu, Apr 23, 2020 at 09:10:16PM -0400, Nathan Schneider wrote:
>
> > How, for example, to collate lines from 3 potentially large files while
> > ensuring they match in length (without an external dependency)? The best
> I
> > can think
On Thu, Apr 23, 2020 at 09:10:16PM -0400, Nathan Schneider wrote:
> How, for example, to collate lines from 3 potentially large files while
> ensuring they match in length (without an external dependency)? The best I
> can think of is rather ugly:
>
> with open('a.txt') as a, open('b.txt') as b,
15 matches
Mail list logo
