[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Tue, Jun 2, 2020, 9:41 AM Steve Dower > > As is, I use islice() or a break inside a loop, but that hypothetical > parameter might be a helpful > > convenience. > > Besides, "zip(iter1, iter2, range(5))" is the same length once you include > the extra unpack, plus it works well with earlier

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Tue, Jun 02, 2020 at 08:52:46PM +1000, Nick Coghlan wrote: > > Truncate at what? > > > > - some maximum length; > > - some specific element; > > - at the shortest input. > > > > Given that the only input parameters are the iterables themselves, it's a > stretch to even consider the first two

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On 02Jun2020 1430, David Mertz wrote: On Tue, Jun 2, 2020 at 8:07 AM Chris Angelico > wrote: > Given that the only input parameters are the iterables themselves, it's a stretch to even consider the first two as possibilities. Why? I can conceivably

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Tue, Jun 2, 2020 at 8:07 AM Chris Angelico wrote: > > Given that the only input parameters are the iterables themselves, it's > a stretch to even consider the first two as possibilities. > > Why? I can conceivably imagine that zip(iter1, iter2, truncate=5) > would consume at most 5 elements

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Tue, Jun 2, 2020 at 8:55 PM Nick Coghlan wrote: > > > > On Tue., 2 Jun. 2020, 11:23 am Steven D'Aprano, wrote: >> >> >> >> > The conceptual idea here is that the "truncate" flag name would technically >> > be a shorter mnemonic for "truncate_silently", so clearing it gives you an >> >

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Tue., 2 Jun. 2020, 11:23 am Steven D'Aprano, wrote: > > > > The conceptual idea here is that the "truncate" flag name would > technically > > be a shorter mnemonic for "truncate_silently", so clearing it gives you > an > > exception rather enabling padding behaviour. > > > > Flipping the

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Mon, Jun 01, 2020 at 09:36:40PM +1000, Nick Coghlan wrote: > zip() can be used to combine iterables of different lengths, including > combining finite iterables with infinite iterators. By default, the output > iterator is implicitly truncated to produce the same number of items as the >

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On 06/01/2020 04:36 AM, Nick Coghlan wrote: Reading this thread and the current PEP, the main question I had was whether it might be better to flip the sense of the flag and call it "truncate". So the status quo would be "truncate=True", while the ValueError could be requested by passing an

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Thu., 21 May 2020, 4:09 am Jim J. Jewett, wrote: > David Mertz wrote: > > > Fwiw, I don't think it changes my order, but 'strict' is a better word > than > > 'equal' in all those places. I'd subtract 0.1 from each of those votes if > > they used "equal". > > I would say that 'equal' is worse

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On 2020-05-21 00:29, Emily Bowman wrote: Python has always preferred full-word over old-school C/Perl/PHP-style abbreviated names. Clarity is paramount. (Or this whole discussion wouldn't even be happening.) [snip] ... apart from len, def, int, float, str, etc.

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

Python has always preferred full-word over old-school C/Perl/PHP-style abbreviated names. Clarity is paramount. (Or this whole discussion wouldn't even be happening.) I think this is *more* of a zip_shortest than zip_strict, but since you can never have total clarity without a method name that

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

I'd like to suggest "len_eq" as a short but (rather) self-explanatory option. On 5/20/20 3:16 PM, Gregory P. Smith wrote: On Wed, May 20, 2020 at 11:09 AM Jim J. Jewett > wrote: David Mertz wrote: > Fwiw, I don't think it changes my order, but 'strict'

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Wed, May 20, 2020 at 11:09 AM Jim J. Jewett wrote: > David Mertz wrote: > > > Fwiw, I don't think it changes my order, but 'strict' is a better word > than > > 'equal' in all those places. I'd subtract 0.1 from each of those votes if > > they used "equal". > > I would say that 'equal' is

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

What about "balanced", "uniform", or "rectangular"? ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Wed, May 20, 2020 at 7:11 PM Jim J. Jewett wrote: > David Mertz wrote: > > > Fwiw, I don't think it changes my order, but 'strict' is a better word > than > > 'equal' in all those places. I'd subtract 0.1 from each of those votes if > > they used "equal". > > I would say that 'equal' is worse

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

David Mertz wrote: > Fwiw, I don't think it changes my order, but 'strict' is a better word than > 'equal' in all those places. I'd subtract 0.1 from each of those votes if > they used "equal". I would say that 'equal' is worse than 'strict'. but 'strict' is also wrong. Zipping to a

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

Gregory P. Smith writes: > Agreed. The best way to reduce accidental incorrect use of the > builtin is to make the builtin capable of doing what a people want > directly without having to go discover something in a module > somewhere. Executive summary: My argument (and one of Steven

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

In the last 24 hours, this thread has grown a bit beyond my capacity to continue several different lines of discussion with each individual. I count 22 messages from 14 different people since my last reply, and I assure you that I've carefully read each response and am considering them as I

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

Ok. That's true. It's technically correct as phrased. I glossed over the "compared to" aspect. I still think it could be made more clear. On Fri, May 15, 2020, 4:40 PM MRAB wrote: > On 2020-05-15 20:36, David Mertz wrote: > > On Fri, May 15, 2020 at 12:55 PM Eric V. Smith >

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Fri, 15 May 2020 at 21:50, Eric V. Smith wrote: > I fear that my comment on some text in the PEP was lost amidst the > voting, so I'm repeating it here. This will probably screw up some > threading, but this is the oldest message I have to reply to. > > The PEP says "At most one additional

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

I fear that my comment on some text in the PEP was lost amidst the voting, so I'm repeating it here. This will probably screw up some threading, but this is the oldest message I have to reply to. The PEP says "At most one additional item may be consumed from one of the iterators when compared

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On 2020-05-15 20:36, David Mertz wrote: On Fri, May 15, 2020 at 12:55 PM Eric V. Smith > wrote: Also: The PEP says "At most one additional item may be consumed from one of the iterators when compared to normal zip usage." I think this should be prefaced

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Fri, May 15, 2020 at 12:55 PM Eric V. Smith wrote: > Also: The PEP says "At most one additional item may be consumed from one > of the iterators when compared to normal zip usage." I think this should > be prefaced with "If ValueError is raised ...". Also, why does it say "at > most one

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Fri, May 15, 2020 at 11:55 AM Henk-Jaap Wagenaar < wagenaarhenkj...@gmail.com> wrote: > I'll join in with the fun... > > zip(strict=True) +1 > itertools.zip_strict() +0 > Agreed. The best way to reduce accidental incorrect use of the builtin is to make the builtin capable of doing what a

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Fri, May 15, 2020 at 11:57 Henk-Jaap Wagenaar wrote: > I'll join in with the fun... > > zip(strict=True) +1 > itertools.zip_strict() +0 > zip(mode='strict') -1 > zip.strict() -1 > Those are exactly how I would vote. -- --Guido (mobile) ___

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

I'll join in with the fun... zip(strict=True) +1 itertools.zip_strict() +0 zip(mode='strict') -1 zip.strict() -1 On Fri, 15 May 2020 at 19:12, Paul Moore wrote: > [Cut the previous votes because someone's quoting didn't survive my > email client and I can't be bothered fixing it] > > If

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

[Cut the previous votes because someone's quoting didn't survive my email client and I can't be bothered fixing it] If everyone else is doing it... itertools.zip_strict() +1 zip(strict=True) -0 zip.strict() -0.5 zip(mode='strict') -1 Paul ___

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On 5/15/2020 11:56 AM, Chris Angelico wrote: On Sat, May 16, 2020 at 1:54 AM Antoine Pitrou wrote: On Fri, 15 May 2020 10:46:25 -0400 David Mertz wrote: 1. +1 itertools.zip_strict function 2. +1 zip.strict(*args) 3. +1 zip(*args, mode='strict') # mode='shortest' by default 4. +0 zip(*args,

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On 15/05/2020 16:56, Chris Angelico wrote: On Sat, May 16, 2020 at 1:54 AM Antoine Pitrou wrote: On Fri, 15 May 2020 10:46:25 -0400 David Mertz wrote: 1. +1 itertools.zip_strict function 2. +1 zip.strict(*args) 3. +1 zip(*args, mode='strict') # mode='shortest' by default 4. +0 zip(*args,

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Sat, May 16, 2020 at 1:54 AM Antoine Pitrou wrote: > > On Fri, 15 May 2020 10:46:25 -0400 > David Mertz wrote: > > > > > 1. +1 itertools.zip_strict function > > > 2. +1 zip.strict(*args) > > > 3. +1 zip(*args, mode='strict') # mode='shortest' by default > > > 4. +0 zip(*args, strict=True) >

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Fri, 15 May 2020 06:06:00 - "Brandt Bucher" wrote: > Ethan Furman wrote: > > Can you do those with _pydecimal? If performance were an issue anywhere I > > would expect to see it with number crunching. > > No difference, probably because those methods look like they spend most of >

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Fri, 15 May 2020 10:46:25 -0400 David Mertz wrote: > > > 1. +1 itertools.zip_strict function > > 2. +1 zip.strict(*args) > > 3. +1 zip(*args, mode='strict') # mode='shortest' by default > > 4. +0 zip(*args, strict=True) > > > > Mostly I agree with Steven on relative preference: > >

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Fri, 15 May 2020 at 16:01, David Mertz wrote: > > I'm a little frustrated by the tone in which the PEP dismisses the option > that is most supported in the discussion. It fine for Brandt to have a > different preference himself, but I think it ought to be presented more > neutrally.

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

I'm a little frustrated by the tone in which the PEP dismisses the option that is most supported in the discussion. It fine for Brandt to have a different preference himself, but I think it ought to be presented more neutrally. On Fri, May 15, 2020, 10:20 AM Steven D'Aprano > 1. +1

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

Here’s another advantage of having a separate function that I didn’t see acknowledged in the PEP: If strict behavior is a better default for a zip-like function than non-strict, then choosing a new function would let you realize that better default. In contrast, by adding a new argument to the

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Fri, May 15, 2020 at 09:56:03AM -0400, Paul Ganssle wrote: > I'm on the fence about using a separate function vs. a keyword argument > (I think there is merit to both), but one thing to note about the > separate function suggestion is that it makes it easier to write > backwards compatible code

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Fri, May 15, 2020 at 08:17:12AM +0100, Paul Moore wrote: > 1. Why do we want to "tempt" people to error when handling mismatched > lengths? Certainly letting people catch errors easily is worthwhile, > but rejecting arguments of different lengths may well *not* be an > error ("be lenient in

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

I'm on the fence about using a separate function vs. a keyword argument (I think there is merit to both), but one thing to note about the separate function suggestion is that it makes it easier to write backwards compatible code that doesn't rely on version checking. With `itertools.zip_strict`,

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

Brandt Bucher writes: > Still agreed. But I think they would be *better* served by the > proposed keyword argument. > > This whole sub-thread of discussion has left me very confused. Was > anything unclear in the PEP's phrasing here? I thought it was quite clear. Those of us who disagree

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Fri, 15 May 2020 at 07:10, Brandt Bucher wrote: > > This whole sub-thread of discussion has left me very confused. Was anything > unclear in the PEP's phrasing here? If so, I'd like to improve it. The > original quote is: "The goal here is not just to provide a way to catch bugs, > but to

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

Ethan Furman wrote: > Can you do those with _pydecimal? If performance were an issue anywhere I > would expect to see it with number crunching. No difference, probably because those methods look like they spend most of their time doing string manipulation: ``` $ export PYPERFSETUP='from

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On 05/14/2020 11:13 AM, Brandt Bucher wrote: I claimed to have found "dozens of other call sites in Python's standard library and tooling where it would be appropriate to enable this new feature". You asked for references, and I provided two dozen cases of zipping what must be equal length

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

Ethan Furman wrote: > So half of your examples are actually counter-examples. I claimed to have found "dozens of other call sites in Python's standard library and tooling where it would be appropriate to enable this new feature". You asked for references, and I provided two dozen cases of

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On 05/14/2020 05:43 AM, Antoine Pitrou wrote: On Wed, 13 May 2020 19:27:57 -0700 Ethan Furman wrote: On 05/13/2020 06:04 AM, Antoine Pitrou wrote: On Tue, 12 May 2020 11:36:38 -0700 Ethan Furman wrote: Also, if a flag is used, won't that slow down every call to zip even when the flag is

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Wed, 13 May 2020 19:27:57 -0700 Ethan Furman wrote: > On 05/13/2020 06:04 AM, Antoine Pitrou wrote: > > On Tue, 12 May 2020 11:36:38 -0700 > > Ethan Furman wrote: > >> > >> Also, if a flag is used, won't that slow down every call to zip even when > >> the flag is False? > > > > Why would

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On 05/13/2020 06:04 AM, Antoine Pitrou wrote: On Tue, 12 May 2020 11:36:38 -0700 Ethan Furman wrote: Also, if a flag is used, won't that slow down every call to zip even when the flag is False? Why would it? Is that based on a rational analysis of how argument parsing works? Not the call

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Wed, May 13, 2020 at 03:04:02PM +0200, Antoine Pitrou wrote: > On Tue, 12 May 2020 11:36:38 -0700 > Ethan Furman wrote: > > > > Also, if a flag is used, won't that slow down every call to zip even when > > the flag is False? > > Why would it? Is that based on a rational analysis of how

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Tue, 12 May 2020 11:36:38 -0700 Ethan Furman wrote: > > Also, if a flag is used, won't that slow down every call to zip even when the > flag is False? Why would it? Is that based on a rational analysis of how argument parsing works? Regards Antoine.

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Wed, May 13, 2020 at 4:38 AM Ethan Furman wrote: > > > - > > https://github.com/python/cpython/blob/27c0d9b54abaa4112d5a317b8aa78b39ad60a808/Lib/os.py#L510 > > Wow -- I don't even know how to parse that! > Wow, that's quite an example. Of something, I'm not sure what, but definitely an

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On 05/11/2020 11:48 PM, Brandt Bucher wrote: On 05/10/2020 14:39, Ethan Furman wrote: On 05/10/2020 09:04 PM, Brandt Bucher wrote: the author has counted dozens of other call sites in Python's standard library and tooling where it would be appropriate to enable this new feature

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On 05/11/2020 11:48 PM, Brandt Bucher wrote: On 05/10/2020 14:39 PM, Ethan Furman wrote: On 05/10/2020 09:04 AM, Brandt Bucher wrote: However, zip_longest is really another beast entirely No, it isn't. It has a completely independent implementation, a different interface, lives in a

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Tue, 12 May 2020 06:48:32 - "Brandt Bucher" wrote: > > > > A good rule of thumb is that "mode-switches" which change return types or > > > significantly alter functionality are indeed an anti-pattern, > > Source? > > This was based on a chat with someone who has chosen not to become

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Tue, May 12, 2020 at 5:20 PM Paul Moore wrote: > > On Tue, 12 May 2020 at 07:53, Brandt Bucher wrote: > > > > Another proposed idiom, per-module shadowing of the built-in zip with > > > > some subtly different variant from itertools, is an anti-pattern that > > > > shouldn't be encouraged.

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Tue, 12 May 2020 at 07:53, Brandt Bucher wrote: > > > However, zip_longest is really another beast entirely > > No, it isn't. > > It has a completely independent implementation, a different interface, lives > in a separate namespace, and doesn't even reference zip in its documentation. > So

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

Thanks for all of your feedback. Antoine Pitrou wrote: > I'm not sure what the iters bring here. The snippet would be more readable > without, IMHO. Good point. I was trying to demonstrate that it works with iterators, but I agree it's clearer to just use the lists here. Ethan Furman wrote:

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Sun, 10 May 2020 16:04:02 - "Brandt Bucher" wrote: > I have pushed a second draft of PEP 618: > > https://www.python.org/dev/peps/pep-0618 > > Please let me know what you think – I'd love to hear any new feedback that > hasn't yet been addressed in the PEP! """ >>> x = iter([iter([1,

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On 05/10/2020 09:04 AM, Brandt Bucher wrote: https://www.python.org/dev/peps/pep-0618 Many Python users find that most of their zip usage I don't think you have enough data to make that claim, unless by "many" you mean five or more. but silently start producing shortened, mismatched

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On 10/05/2020 17:04, Brandt Bucher wrote: I have pushed a second draft of PEP 618: https://www.python.org/dev/peps/pep-0618 Please let me know what you think – I'd love to hear any new feedback that hasn't yet been addressed in the PEP! I still don't buy your dismissal of the new function