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. Source?

Point taken. I probably went a bit far labeling this a straight-up "anti-pattern", but it is certainly annoying to find that someone has added `from pprint import pprint as print` at the top of a module, for example (which has actually happened to me before). Very hard to figure out what's happening.

Also irrelevant. It's very easy to suggest bad ways of using a feature. That doesn't make the feature bad. You seem to be arguing that zip_strict is bad because people can misuse it. We could probably remove 99% of the Python language by that argument...

And considering that "from __future__ import print_function" is an officially-sanctioned way to cause a semantic change to print, I don't think it's really that strong an argument. Python is *deliberately* designed so that you can shadow things. I am most in favour of the separate-functions option *because* it makes shadowing easy. Not an anti-pattern at all. ChrisA

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 to normal zip usage." I think this should be prefaced with "If ValueError is raised ...". Also, why does it say "at most one additional item". How could it ever be less than one? And I'm not sure I'd say "normal zip usage", maybe "the existing builtin zip function". Eric

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 separate namespace,

- both take an unknown number of iterables - both return tuples - both names start with `zip` - both stop at exhaustion - one as soon as possible - the other as late as possible - one has one extra parameter Those seem like very similar beasts to me.

and doesn't even reference zip in its documentation.

So update the docs. -- ~Ethan~

On Wed, May 13, 2020 at 4:38 AM Ethan Furman wrote:

...

- https://github.com/python/cpython/blob/27c0d9b54abaa4112d5a317b8aa78b39ad60a...

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 example. Based on two booleans, entries is either None or a list. If it's None, this loops over just the directory names; if it's a list, then it's been populated in perfect parallel to dirs (see the preceding loop), thus guaranteeing that the two lists are perfectly parallel. But in that case, "name" actually gets a tuple of (name,entry), and then inside the loop, it does a three-way branch that is guaranteed (and asserted) to split out the name and entry ONLY when there actually will be one. Definitely an odd piece of code. But it can never zip over things of different lengths. ChrisA

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 argument parsing works?

I'm not an expert on Python's argument passing code in fine detail, but I'm reasonable sure that it takes longer to pass arguments by keyword than by position, and it takes time to fill in missing arguments with the default (they have to be read from the function defaults, which takes time) and these things don't happen for free. But I do think that's probably a spurious point based on a micro- or even nano-optimization. I don't think that the extra nanosecond or whatever it takes for zip to receive an extra argument, fill in the default if missing, and branch is significant. I don't think that `zip(*args, strict=flag)` is the wrong choice because it's a nanosecond slower, I think it's the wrong choice because it makes for a poorer API when there are better, more future-proof choices available. -- Steven

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 it? Is that based on a rational analysis of how argument parsing works?

Not the call itself, but the running of zip. Absent some clever programming it seems to me that there are two choices if we have a flag:

- have two independent branches (basically `zip` and a `zip_strict` functions inside `zip` itself) and have the flag select the branch; or

- have one branch which has extra logic that checks for at least one StopIteration and at least one item in each iteration to see if it should raise.

And how much do you think that costs, compared to the overall cost of running the entire zip() function, including consumption of yielded results by the calling frame?

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 what you accept" is a well-known principle, even if not something that everyone agrees on in all cases).

I concur with Paul here. There may be cases where mismatched lengths are an error, but there are also cases where they are not an error. It is patronising to be talking about tempting people into using the strict version of zip. People who need it will find it, whether it is builtin or not.

2. I find "mode switch" arguments ugly

I think we need to distinguish between *modes* and *flags*. This proposed functionality is a mode, not a flag. Mode switches are extensible: zip(*args, mode='strict') can easily be extended in the future to support new modes, such as zip_longest. There are at least two other modes that have been mentioned briefly in the Python-Ideas thread: 1. a variety of zip that returns information in the StopIterator exception identifying the argument that was empty and those that weren't; 2. a variety of zip that simply skips the missing arguments: zip_skip('abc', 'ef', 'g') => (a, e, g) (b, f), (c,) I don't even understand the point of the first one, or how it would operate in practice, or why anyone would need it, but at least one person thinks it would be useful. Take that as you will. But I have written my own version of the second one, and used it. A mode parameter naturally implies that only one mode can apply at a time, and it naturally enforces that restriction without any additional programmer effort. If there are (let's say...) four different modes: mode = shortest|longest|strict|skip you can only supply one at a time. Using *named modes* (whether as strings or enums) to switch modes is quite reasonable. It's not my preferred API for this, but I don't hate it. But a *flag* parameter is difficult to extend without making both the API and the implementation complicated, since any extension will use multiple parameters: zip(*args, strict=True, longest=False, skip=True) and the caller can supply any combination, each of which has to be tested for, exceptions raised for the incompatible combinations. With three flags, there are eight such combinations, but only four valid ones. With four flags, there are 16 combinations and only five meaningful combinations. Flags work tolerably well when the parameters are independent and orthogonal, so you can ask for any combination of flags. But flags to switch modes are *not* independent and orthogonal. We can't combine them in arbitrary combinations. Using *boolean flags* to switch modes in this way makes for a poor API. For the record, my preferred APIs for this are in order: 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) and even that is being generous for option 4. Note that options 1 and 2 have an important advantage over options 3 and 4: the strict version of zip is a first-class callable object that can be directly passed around and used indirectly in a functional way. E.g. for testing using unittest: assertRaises(zip.strict, 'a', '', Exception) Yes, assertRaises is also usable as a context manager, but this is just an illustration of the functional style. -- Steven

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.

Agreed. The PEP gives the impression that consensus was reached, but I don't think that's the case. My feeling is that opinions are rather evenly split between the approach in the PEP and an itertools function. I also feel that proposing an itertools function would have been a *lot* less controversial, so the tone in the PEP feels a little like it's defending a weak position by aggressively opposing alternatives. After all, one of the benefits of an itertools function is that it probably wouldn't have needed a PEP in the first place! Actually, looking at the reasons for rejection of the itertools option in the PEP:

It seems that a great deal of the motivation driving this alternative is that zip_longest already exists in itertools.

Nope, the biggest motivation is that an itertools addition would have been *significantly less controversial*. Paul

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)

Mostly I agree with Steven on relative preference:

itertools.zip_strict() +1 zip.strict() +0.5 zip(mode='strict') +0 zip(strict=True) -0.5

For me:

* zip(strict=True) +1 * zip(mode='strict') -0 * itertools.zip_strict() -0.5 * zip.strict() -1 (but really, I'd like to make this -1e10)

Since we're posting: itertools.zip_strict() +1 zip.strict() +0.1 zip(strict=True) -0.5 zip(mode='strict') -1 ChrisA

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, strict=True)

Mostly I agree with Steven on relative preference:

itertools.zip_strict() +1 zip.strict() +0.5 zip(mode='strict') +0 zip(strict=True) -0.5 For me:

* zip(strict=True) +1 * zip(mode='strict') -0 * itertools.zip_strict() -0.5 * zip.strict() -1 (but really, I'd like to make this -1e10)

Since we're posting:

itertools.zip_strict() +1 zip.strict() +0.1 zip(strict=True) -0.5 zip(mode='strict') -1

itertools.zip_strict() +1 zip.strict() +0 zip(strict=True) -0 zip(mode='strict') -1 I don't particularly care for "strict", though. It doesn't seem specific enough, and doesn't say "they iterators must return the same number of items" to me. I sort of liked "equal" better, but not so much to make a big stink about it. Also: The PEP says "At most one additional item may be consumed from one of the iterators when compared to normalzip usage." I think this should be prefaced with "If ValueError is raised ...". Also, why does it say "at most one additional item". How could it ever be less than one? Eric

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 everyone else is doing it...

itertools.zip_strict() +1 zip(strict=True) -0 zip.strict() -0.5 zip(mode='strict') -1

Paul _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4YDZH7E6... Code of Conduct: http://python.org/psf/codeofconduct/

These negative votes surprise me. Given that it's clear that a generic strict-mode zip is non-trivial to write, and that there is significant demand for it, are people saying "+0 Python would not be a better programming environment if itertools.zip_strict() were adopted," and "-1 Python would be a worse programming environment if zip.strict() were adopted"? I can see why folks would say the latter about zip.strict(), but even though I really dislike the mode switches, I'm still positive about adding them if one of them ranks highest among those who care. I'm not going to give them negative votes, they don't make Python worse. I don't mind hyperbole ("I'm +1000 on this feature!" or "-10 on the worst proposal I've seen since <potentially controversial example removed>!") But I would like it if "0" meant "indifferent", "+1" meant "no-brainer, add it", and "-1" meant "no-brainer, just don't". FWIW, +1 itertools.zip_strict(*iterables) +0.5 zip(*iterables, mode) # mode is 3-way, default "shortest" +0.4 zip(*iterables, strict) # strict is boolean, default False +0 zip.strict(*iterables)

On Fri, May 15, 2020 at 11:55 AM Henk-Jaap Wagenaar < wagenaarhenkjaap@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 people want directly without having to go discover something in a module somewhere. OTOH so long as zip's docstring that shows up to people from interactive help, pydoc, and hover/alt/meta text in fancier IDEs mentions the caveat and the way to get the strict behavior, either of these two should be sufficient. I'm pushing forward with a pure documentation update in https://github.com/python/cpython/pull/20118 suitable for 3.8 - it doesn't mention the way to get the other behavior as that isn't settled or short yet, just makes it more obvious what the actual behavior is. -gps

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 additional item". How could it ever be less than one?

This struck me as strange also. I mean, the wording can be improved to clarify "if error." But more significantly, it seems like it cannot conceivably be true. If might be "At most one additional item from EACH of the iterators." If I do zip_strict(a, b, c, d, e) and "e" is the one that is shorter, how could any algorithm ever avoid consuming one extra item of a, b, c, and d each?! -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.

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 mailto:eric@trueblade.com> 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 additional item". How could it ever be less than one?

This struck me as strange also. I mean, the wording can be improved to clarify "if error."

But more significantly, it seems like it cannot conceivably be true. If might be "At most one additional item from EACH of the iterators."

If I do zip_strict(a, b, c, d, e) and "e" is the one that is shorter, how could any algorithm ever avoid consuming one extra item of a, b, c, and d each?!

Well, it does say "when compared to normal zip usage".

The normal zip would consume an item of a, b, c, and d. If e is exhausted, then zip would just stop, but zip_strict would raise ValueError. There would be no difference in the number of items consumed but not used. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5B26LEJY... Code of Conduct: http://python.org/psf/codeofconduct/

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 than 'strict'. but 'strict' is also wrong.

Zipping to a potentially infinite sequence -- like a manual enumerate -- isn't wrong. It may be the less common case, but it isn't wrong. Using 'strict' implies that there is something sloppy about the data in, for example, cases like Stephen J. Turnbull's lagged time series.

Unfortunately, the best I can come up with is 'same_length', or possibly 'equal_len' or 'equal_length'. While those are better semantically, they are also slightly too long or awkward. I would personally still consider 'same_length' the least bad option.

conformant? similar? parallel?

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 worse than 'strict'. but 'strict' is also wrong.

Zipping to a potentially infinite sequence -- like a manual enumerate -- isn't wrong. It may be the less common case, but it isn't wrong. Using 'strict' implies that there is something sloppy about the data in, for example, cases like Stephen J. Turnbull's lagged time series.

Unfortunately, the best I can come up with is 'same_length', or possibly 'equal_len' or 'equal_length'. While those are better semantically, they are also slightly too long or awkward. I would personally still consider 'same_length' the least bad option.

-jJ

As we've come down to naming things... if you want it to read more like English, `zip(vorpal_rabbits, holy_hand_grenades, lengths_must_match=True)` or another chosen variation of that such as `len_must_match=` or `length_must_match=` reads nicely and is pretty self explanatory that an error can be expected if the condition implied by the "must" is found untrue without really feeling a need to look it up in documentation. It is also harder to type or fit on a line. Which is one advantage to a short thing like `strict=`. I don't care so much about the particular spelling here to argue among any of those, I primarily want the feature to exist. I expect we're entering steering council territory for a decision soon... -gps _______________________________________________

Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/G5JTZI6S... Code of Conduct: http://python.org/psf/codeofconduct/

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 doubles as a docstring, whatever works will work as long as it's documented. Em On Wed, May 20, 2020 at 3:33 PM Joseph Jenne via Python-Dev < python-dev@python.org> wrote:

I'd like to suggest "len_eq" as a short but (rather) self-explanatory option.

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 than 'strict'. but 'strict' is also wrong.

Zipping to a potentially infinite sequence -- like a manual enumerate -- isn't wrong. It may be the less common case, but it isn't wrong. Using 'strict' implies that there is something sloppy about the data in, for example, cases like Stephen J. Turnbull's lagged time series.

Unfortunately, the best I can come up with is 'same_length', or possibly 'equal_len' or 'equal_length'. While those are better semantically, they are also slightly too long or awkward. I would personally still consider 'same_length' the least bad option.

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 explicit "truncate=False". Draft documentation paragraph: ====== 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 shortest input iterable. Setting *truncate* to false disables this implicit truncation and raises ValueError instead. Note that if this ValueError is raised an additional item will have been consumed from any iterators listed before the shortest iterator (or from the second listed iterator if the first iterator is the shortest one). To pad shorter input iterables rather than truncating the output or raising ValueError, see itertools.zip_longest. ====== 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 sense of the flag also means that "truncate=True" will appear in IDE tooltips as part of the function signature, providing significantly more information than "strict=False" would. That improved self-documentation then becomes what I would consider the strongest argument in favour of the flag-based approach: providing more information up-front to users regarding the actual behaviour of the builtin, rather than having them incorrectly assume that mismatched input iterator lengths will raise an exception. Side note: this idea pairs nicely with the "zip(itr, itr, ir)" idiom for non-overlapping data windows, as it makes it straightforward to request an exception if the last data tuple has values missing (without the flag, the idiom silently discards incomplete trailing data). Cheers, Nick. P.S. I had the opportunity to read the thread from beginning to end after belatedly catching some of the messages out of context, and FWIW, I started out assuming I would strongly favour the itertools function option, and surprised myself by favouring the flag option (albeit inverted) by the time I reached the end.

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 shortest input iterable. Setting *truncate* to false disables this implicit truncation and raises ValueError instead.

It's not really *implicit* if there's an explicit flag controlling the behaviour, even with a default value. We don't use that sort of language elsewhere. For example, help(sorted) doesn't say: "Return a new list containing all items from the iterable implicitly in ascending order. Pass reverse=True to disable this implicit order." help(int) doesn't say that the base is implicitly decimal; help(print) doesn't talk about "implicit spaces between items, implicit newline at the end of the output" etc. It just states the behaviour controlled by the parameter. This is accurate, non-judgemental, and avoids being over-wordy: "By default, the output iterator is truncated at the shortest input iterable."

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 sense of the flag also means that "truncate=True" will appear in IDE tooltips as part of the function signature, providing significantly more information than "strict=False" would.

"Significantly" more? I don't think so. Truncate at what? - some maximum length; - some specific element; - at the shortest input. At some point people have to read the docs, not just the tooltips. If you didn't know what zip does, seeing truncate=True won't mean anything to you. If you do know what zip does, then the parameter names are mnemonics, and strict=False and truncate=True provide an equal hint for the default behaviour: * if it's not strict, it is tolerant, stopping at the shortest; * if it truncates, it truncates at the shortest input. For the default case, strict=False and truncate=True are pretty much equal in information. But for the case of non-default behaviour, strict=True is a clear winner. It can pretty much only mean one thing: raise an exception. Whereas truncate=False is ambiguous: - pad the output; - skip items as they become empty; - raise an exception. All three of these are useful behaviour, and while the middle one is not part of this PEP, it was requested in the discussions on Python-Ideas.

That improved self-documentation then becomes what I would consider the strongest argument in favour of the flag-based approach:

I don't think that "truncate=False" (which can mean three different things) is more self-documenting than `zip(*items, mode='strict')` or `zip_strict()` (either of which can only mean one thing). -- Steven

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 exception rather enabling padding behaviour.

Flipping the sense of the flag also means that "truncate=True" will appear in IDE tooltips as part of the function signature, providing significantly more information than "strict=False" would.

"Significantly" more? I don't think so.

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 as possibilities.

Why? I can conceivably imagine that zip(iter1, iter2, truncate=5) would consume at most 5 elements from each iterable. It's not much of a stretch. It doesn't happen to be what's proposed, but it's a reasonable interpretation. (Though then the default would probably be truncate=None to not truncate.) ChrisA

On 02Jun2020 1430, David Mertz wrote:

On Tue, Jun 2, 2020 at 8:07 AM Chris Angelico mailto:rosuav@gmail.com> 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 from each iterable. It's not much of a stretch. It doesn't happen to be what's proposed, but it's a reasonable interpretation. (Though then the default would probably be truncate=None to not truncate.)

This was exactly my thought, that Chris wrote very well.  I can easily imagine a 'truncate=5' behavior.  In fact, if it existed, it is something I would have used multiple times.  As is, I use islice() or a break inside a loop, but that hypothetical parameter might be a helpful convenience.

However, it is indeed NOT the current proposal or discussion.

Besides, "zip(iter1, iter2, range(5))" is the same length once you include the extra unpack, plus it works well with earlier versions. Cheers, Steve

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 as possibilities.

And then:

"strict=False" doesn't tell you whether the tolerant behaviour is truncation or padding. "truncate=True" does.

You can't have it both ways Nick -- if the lack of additional parameters is enough for the user to predict that the only reasonable behaviour is to truncate, then the lack of additional parameters is also enough for them to predict that the only reasonable non-strict (tolerant) behaviour is to truncate at the shortest input. [...]

...

But for the case of non-default behaviour, strict=True is a clear winner. It can pretty much only mean one thing: raise an exception.

But raise an exception when? In the context of this discussion, we know we mean "strict length checking, raising an exception for inconsistent lengths".

But "strict" on its own doesn't convey that - we could be requesting strict runtime type checking, for example, where each iterable is expected to keep producing items of the same type as was produced for the first tuple. Or we could be requesting a check that the values in the tuple aren't "None".

If you are going to propose that users might imagine a hypothetical check that raises if any item is None, well, isn't that *precisely* the sentinel check I gave above that you blithly dismissed as "a stretch"? If it's a stretch for me, it's a stretch for you too. Ultimately, bikeshedding on the name truncate versus strict versus equal versus shortest versus ... is quibbling. Everyone who reads the tooltips, assuming they even see them, is going to take something different from it. Some will think "truncate what, the tuples?" and some will think "strict about what?". Ultimately the tooltips are no substitute for reading the docs. If you don't know what zip does, you cannot interpret what it means for zip to truncate or be strict. No one single word is going to communicate everything we need to communicate. Function and parameter names are mnemonics, not documentation. So on that note, and in regard only to the choice between "strict" versus "truncate" etc, I'm going to bow out: call it what you will. I've got a bigger problem with the use of a boolean flag than the name. -- Steven

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`, you can do some graceful degradation like so: try:     from itertools import zip_strict except ImportError:     zip_strict = zip Or provide fallback easily: try:     from itertools import zip_strict except ImportError:     def zip_strict(*args):         yield from zip(*args)         for arg in args:             if next(arg, None):                  raise ValueError("At least one input terminated early.") There's an alternate pattern for the kwarg-only approach, which is to just try it and see: try:     zip(strict=True)     HAS_ZIP_STRICT = True except TypeError:     HAS_ZIP_STRICT = False But I would say it's considerably less idiomatic. Just food for thought here. In the long run this doesn't matter, because eventually 3.9 will fall out of everyone's support matrices and these workarounds will become obsolete anyway. Best, Paul On 5/15/20 5:20 AM, Stephen J. Turnbull wrote:

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 simply disagree. We prefer to provide it as a separate function. Just move on, please; you're not going to convince us, and we're not going to convince you. Leave it to the PEP Delegate or Steering Council.

...

I wouldn't confuse "can" and "should" here.

You do exactly that in arguing for your preferred design, though.

We could implement the strictness test with an argument to the zip builtin function, but I don't think we should. I still can't think of a concrete use case for it from my own experience. Of course I believe concrete use cases exist, but that introspection makes me suspicious of the claim that this should be a builtin feature, with what is to my taste an ugly API.

Again, I don't expect to convince you, and you shouldn't expect to convince me, at least not without more concrete and persuasive use cases than I've seen so far.

Steve _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6NQZIDVM... Code of Conduct: http://python.org/psf/codeofconduct/

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 existing function, the function you use will forever have the less preferred default. In terms of what is a better default, I would say strict is better because errors can’t pass silently: If errors occur, you can always change the flag. But you would be doing that explicitly. —Chris On Fri, May 15, 2020 at 6:57 AM 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 that doesn't rely on version checking. With `itertools.zip_strict`, you can do some graceful degradation like so:

try: from itertools import zip_strict except ImportError: zip_strict = zip

Or provide fallback easily:

try: from itertools import zip_strict except ImportError: def zip_strict(*args): yield from zip(*args) for arg in args: if next(arg, None): raise ValueError("At least one input terminated early.")

There's an alternate pattern for the kwarg-only approach, which is to just try it and see:

try: zip(strict=True) HAS_ZIP_STRICT = True except TypeError: HAS_ZIP_STRICT = False

But I would say it's considerably less idiomatic.

Just food for thought here. In the long run this doesn't matter, because eventually 3.9 will fall out of everyone's support matrices and these workarounds will become obsolete anyway.

Best, Paul

On 5/15/20 5:20 AM, Stephen J. Turnbull wrote:

...

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 simply disagree. We prefer to provide it as a separate function. Just move on, please; you're not going to convince us, and we're not going to convince you. Leave it to the PEP Delegate or Steering Council.

...

I wouldn't confuse "can" and "should" here.

You do exactly that in arguing for your preferred design, though.

We could implement the strictness test with an argument to the zip builtin function, but I don't think we should. I still can't think of a concrete use case for it from my own experience. Of course I believe concrete use cases exist, but that introspection makes me suspicious of the claim that this should be a builtin feature, with what is to my taste an ugly API.

Again, I don't expect to convince you, and you shouldn't expect to convince me, at least not without more concrete and persuasive use cases than I've seen so far.

Steve _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6NQZIDVM... Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/A4UGQRMK... Code of Conduct: http://python.org/psf/codeofconduct/