[Python-ideas] Re: zip(x, y, z, strict=True)

On 12/1/22 11:36, Ram Rachum wrote: > Reviving this thread 2.5 years after I started it just to share this satisfying moment... Very cool! Always enjoyable to benefit from the fruits of one labors. :-) -- ~Ethan~ ___ Python-ideas mailing list --

[Python-ideas] Re: zip(x, y, z, strict=True)

I liked your idea so much back when you suggested it that I implemented it in our sitecustomize.py back when we were using 3.8, and added a check to our lint tools to require that the 'strict=' parameter be present in all uses of 'zip'. We found a couple of silent bugs almost immediately, so

[Python-ideas] Re: zip(x, y, z, strict=True)

Reviving this thread 2.5 years after I started it just to share this satisfying moment. I was just spending a few hours furiously coding on my research using Python 3.10, and when I ran my code I got this traceback: File

[Python-ideas] Re: zip(x, y, z, strict=True)

> On May 9, 2020, at 04:30, Alex Hall wrote: >  >> On Fri, May 8, 2020 at 11:22 PM Andrew Barnert via Python-ideas >> wrote: > >> Trying to make it a flag (which will always be passed a constant value) is a >> clever way to try to get the best of both worlds—and so is the >>

[Python-ideas] Re: zip(x, y, z, strict=True)

On Fri, May 8, 2020 at 11:22 PM Andrew Barnert via Python-ideas < python-ideas@python.org> wrote: > Trying to make it a flag (which will always be passed a constant value) is > a clever way to try to get the best of both worlds—and so is the > chain.from_iterable style. At this point it sounds

[Python-ideas] Re: zip(x, y, z, strict=True)

On May 5, 2020, at 12:50, Christopher Barker wrote: > > Another key point is that if you want zip_longest() functionality, you simply > can not get it with the builtin zip() -- you are forced to look elsewhere. > Whereas most code that might want "strict" behavior will still work, albeit >

[Python-ideas] Re: zip(x, y, z, strict=True)

On Wed, May 06, 2020 at 08:48:51AM -0700, Christopher Barker wrote: [I asked] > > A ternary flag of strict = True, False or what? > > > > Come on: > > ternary: having three elements, parts, or divisions ( > https://www.merriam-webster.com/dictionary/ternary) > > did you really not know that?

[Python-ideas] Re: zip(x, y, z, strict=True)

On Thu, May 7, 2020 at 3:07 AM Christopher Barker wrote: > On Wed, May 6, 2020 at 1:42 PM Kirill Balunov > wrote: > >> I'm totally agree with everything you said here. From my perspective, >> comparing three main cases: >> 1. zip(*iters, strict= (False | True)) >> 2. zip(*iters, mode =

[Python-ideas] Re: zip(x, y, z, strict=True)

On Thu, 7 May 2020 at 01:07, Christopher Barker wrote: > 3) Add a ternary mode flag to zip > zip(*iters, mode = ('shortest' | 'equal' | 'longest'), fillvalue=None) You missed itertools.zip_longest(*iters, fillvalue=None) from this one. Unless you're proposing to drop itertools.zip_longest, the

[Python-ideas] Re: zip(x, y, z, strict=True)

On Wed, May 6, 2020 at 1:42 PM Kirill Balunov wrote: > I'm totally agree with everything you said here. From my perspective, > comparing three main cases: > 1. zip(*iters, strict= (False | True)) > 2. zip(*iters, mode = ('shortest' | 'equal' | 'longest')) > 3. zip_equal(*iters) > Thanks for

[Python-ideas] Re: zip(x, y, z, strict=True)

On Wed, May 6, 2020 at 6:49 PM Christopher Barker wrote: > On Tue, May 5, 2020 at 5:43 PM Steven D'Aprano > wrote: > >> Christopher's quoting is kinda messed up and I can't be bothered fixing >> it, sorry, so you'll just have to guess who said what :-) >> > > Ideally, we are evaluating ideas

[Python-ideas] Re: zip(x, y, z, strict=True)

On Mon, 27 Apr 2020 13:39:19 -0700 Christopher Barker wrote: > There is one "downside" to this in that it potentially leaves the > iterators passed in in a undetermined state -- partially exhausted, > and with a longer one having had one more item removed than was > used. But that exists with

[Python-ideas] Re: zip(x, y, z, strict=True)

On 2020-05-06 12:48 p.m., Christopher Barker wrote: On Tue, May 5, 2020 at 5:43 PM Steven D'Aprano > wrote: Christopher's quoting is kinda messed up and I can't be bothered fixing it, sorry, so you'll just have to guess who said what :-) Ideally, we

[Python-ideas] Re: zip(x, y, z, strict=True)

On Tue, May 5, 2020 at 7:20 AM Steven D'Aprano wrote: > On Mon, Apr 27, 2020 at 01:39:19PM -0700, Christopher Barker wrote: > > > Can you think of a single case where a zip_equal() (either pre-exisiting > or > > roll your own) would not work, but the concretizing version would? > > That's

[Python-ideas] Re: zip(x, y, z, strict=True)

On Tue, May 5, 2020 at 5:43 PM Steven D'Aprano wrote: > Christopher's quoting is kinda messed up and I can't be bothered fixing > it, sorry, so you'll just have to guess who said what :-) > Ideally, we are evaluating ideas independently of who expressed them, so I'll pretend I did that on

[Python-ideas] Re: zip(x, y, z, strict=True)

On Mon, 4 May 2020 at 12:41, Steven D'Aprano wrote: > > On Sun, May 03, 2020 at 11:13:58PM -0400, David Mertz wrote: > > > It seems to me that a Python implementation of zip_equals() shouldn't do > > the check in a loop like a version shows (I guess from more-itertools). > > More obvious is the

[Python-ideas] Re: zip(x, y, z, strict=True)

On Tue, May 05, 2020 at 12:49:05PM -0700, Christopher Barker wrote: > Agreed, but discoverability is still something to be considered in the API. > ANd it seems that there are folks arguing that we specifically want this to > be less discoveble due to concerns of overuse. Which does not seem like

[Python-ideas] Re: zip(x, y, z, strict=True)

Christopher's quoting is kinda messed up and I can't be bothered fixing it, sorry, so you'll just have to guess who said what :-) On Tue, May 05, 2020 at 01:03:30PM -0700, Christopher Barker wrote: > "If its builtin people will be more likely to use it, so we need to make > > it builtin." > >

[Python-ideas] Re: zip(x, y, z, strict=True)

On 05/05/2020 21:03, Christopher Barker wrote: "If its builtin people will be more likely to use it, so we need to make it builtin." This argument will apply to **literally** every function and class in the standard library. But we are not talking adding a new builtin. Well, actually we

[Python-ideas] Re: zip(x, y, z, strict=True)

"If its builtin people will be more likely to use it, so we need to make > it builtin." > > This argument will apply to **literally** every function and class in > the standard library. But we are not talking adding a new builtin. > Firstly, we would have to agree that "maximizing the number

[Python-ideas] Re: zip(x, y, z, strict=True)

On Tue, May 5, 2020 at 9:20 AM David Mertz wrote: > I have no idea whether a flag on zip() or a function in itertools would > get MORE USE. I *ABSOLUTELY* think it is an anti-goal to get more use for > its own sake though. > I'm not sure anyone was suggesting that -- *maybe* Alex, but I think

[Python-ideas] Re: zip(x, y, z, strict=True)

On Wed, May 6, 2020 at 3:25 AM Steven D'Aprano wrote: > Personally, I don't think Chris' backwards-compatibility argument is > strong. Technically adding a new keyword argument to a function is > backwards-incompatible, but we normally exclude that sort of change. Who > writes this? > > #

[Python-ideas] Re: zip(x, y, z, strict=True)

On Tue, 5 May 2020, 18:24 Steven D'Aprano, wrote: > On Tue, May 05, 2020 at 05:26:02PM +0100, Henk-Jaap Wagenaar wrote: > > > This is a straw man in regards to backwards compatibility. This > particular > > (sub)thread is about whether if this zip-is-strict either as a separate > > name or a

[Python-ideas] Re: zip(x, y, z, strict=True)

On Tue, May 05, 2020 at 05:28:08PM +0100, Henk-Jaap Wagenaar wrote: > But you care about your input, you can do so by setting strict=True (if > that's the road we go down), and unlike what others have said, the IDE I > use (pycharm) would tell me that flag exists as I type "zip" and so I'd be >

[Python-ideas] Re: zip(x, y, z, strict=True)

On Tue, May 05, 2020 at 05:26:02PM +0100, Henk-Jaap Wagenaar wrote: > This is a straw man in regards to backwards compatibility. This particular > (sub)thread is about whether if this zip-is-strict either as a separate > name or a Boolean flag or some other flag of zip should be a built-in or be

[Python-ideas] Re: zip(x, y, z, strict=True)

On 05/05/2020 17:26, Henk-Jaap Wagenaar wrote: This is a straw man in regards to backwards compatibility. This particular (sub)thread is about whether if this zip-is-strict either as a separate name or a Boolean flag or some other flag of zip should be a built-in or be in e.g. itertools. It is

[Python-ideas] Re: zip(x, y, z, strict=True)

But you care about your input, you can do so by setting strict=True (if that's the road we go down), and unlike what others have said, the IDE I use (pycharm) would tell me that flag exists as I type "zip" and so I'd be more likely to use it than if it was in itertools/... On Tue, 5 May 2020,

[Python-ideas] Re: zip(x, y, z, strict=True)

This is a straw man in regards to backwards compatibility. This particular (sub)thread is about whether if this zip-is-strict either as a separate name or a Boolean flag or some other flag of zip should be a built-in or be in e.g. itertools. It is not about breaking backwards compatibility

[Python-ideas] Re: zip(x, y, z, strict=True)

I have no idea whether a flag on zip() or a function in itertools would get MORE USE. I *ABSOLUTELY* think it is an anti-goal to get more use for its own sake though. I'm +1 on a new function in itertools, maybe +0 or maybe -0 on a flag. But I only want APPROPRIATE USE in any case. The API

[Python-ideas] Re: zip(x, y, z, strict=True)

On Wed, May 6, 2020 at 1:44 AM Rhodri James wrote: > > On 05/05/2020 13:53, Henk-Jaap Wagenaar wrote: > > Brandt's example with ast in the stdlib I think is a pretty good example of > > this. > > > > On Tue, 5 May 2020 at 13:27, Rhodri James wrote: > > > >> On 05/05/2020 13:12, Henk-Jaap

[Python-ideas] Re: zip(x, y, z, strict=True)

On 05/05/2020 13:53, Henk-Jaap Wagenaar wrote: Brandt's example with ast in the stdlib I think is a pretty good example of this. On Tue, 5 May 2020 at 13:27, Rhodri James wrote: On 05/05/2020 13:12, Henk-Jaap Wagenaar wrote: A function that is a "safer" version in some "edge case" (not

[Python-ideas] Re: zip(x, y, z, strict=True)

On Mon, Apr 27, 2020 at 01:39:19PM -0700, Christopher Barker wrote: > Can you think of a single case where a zip_equal() (either pre-exisiting or > roll your own) would not work, but the concretizing version would? That's easy: if the body of your zip-handling function has side-effects which

[Python-ideas] Re: zip(x, y, z, strict=True)

Brandt's example with ast in the stdlib I think is a pretty good example of this. On Tue, 5 May 2020 at 13:27, Rhodri James wrote: > On 05/05/2020 13:12, Henk-Jaap Wagenaar wrote: > > A function that is a "safer" version in some "edge case" (not extra > > functionality but better error handling

[Python-ideas] Re: zip(x, y, z, strict=True)

On 05/05/2020 13:12, Henk-Jaap Wagenaar wrote: A function that is a "safer" version in some "edge case" (not extra functionality but better error handling basically) but that does otherwise work as expected is not something one will search for automatically. This is zip versus

[Python-ideas] Re: zip(x, y, z, strict=True)

I feel like that argument is flawed. I cannot think of another good example (I am sure there are plenty!) but there is a big difference for discoverability between: A function that does something *different* and functionality does not exist in a built-in (or whatever namespace you are

[Python-ideas] Re: zip(x, y, z, strict=True)

On Tue, 5 May 2020 at 07:22, Christopher Barker wrote: > In any case, you seem to making the argument that a few of us are putting > forward: yes, a flag on zip() is likely to get more use than a function in > itertools. Thanks for the support :-) I'd like to add my voice to the people saying

[Python-ideas] Re: zip(x, y, z, strict=True)

Steven: I understand that Alex said he thought that putting "strict" in as a flag would make it a bit more likely that people would use, and that he thinks that's a good thing, and you think that's a bad thing, but... Unless we were to make it the default behavior, very few people are going to

[Python-ideas] Re: zip(x, y, z, strict=True)

On 05/04/2020 12:07 PM, Alex Hall wrote: No, I stand by my position for now that "just in case" is a genuine reason "just in case" is boiler-plate. One of the huge wins in Python is its low boiler-plate requirements. It's okay if programmers have to think about their code and what's

[Python-ideas] Re: zip(x, y, z, strict=True)

On 05/04/2020 12:35 PM, Alex Hall wrote: I imagine there are few people who are too lazy to copy code from SO right now, and would be too lazy to import from itertools when the feature becomes available, but if it's a builtin then they're willing to make changes Quite frankly, I have zero

[Python-ideas] Re: zip(x, y, z, strict=True)

On Mon, May 04, 2020 at 09:20:28PM +0200, Alex Hall wrote: > > Seriously, if some object defines a weird `__eq__` then half the > > standard library, including builtins, stops working "correctly". See for > > example the behaviour of float NANs in lists. > > > > My care factor for this is

[Python-ideas] Re: zip(x, y, z, strict=True)

On Mon, 4 May 2020 21:07:26 +0200 Alex Hall wrote: > Yes. We're starting to go in circles here, but I'm arguing that it's > OK for people to be mildly inconvenienced sometimes having to > preemptively trim their inputs in exchange for less confusing, > invisible, frustrating bugs. I'd like

[Python-ideas] Re: zip(x, y, z, strict=True)

On Mon, May 4, 2020 at 9:18 PM Chris Angelico wrote: > On Tue, May 5, 2020 at 5:11 AM Alex Hall wrote: > > > > On Mon, May 4, 2020 at 1:59 AM Steven D'Aprano > wrote: > >> Can we agree to meet half-way? > >> > >> - there are legitimate, genuine uses for zip_strict; > >> > >> - but encouraging

[Python-ideas] Re: zip(x, y, z, strict=True)

On Mon, May 4, 2020 at 2:33 AM Steven D'Aprano wrote: > On Sat, May 02, 2020 at 07:43:44PM +0200, Alex Hall wrote: > > On Sat, May 2, 2020 at 6:09 PM Steven D'Aprano > wrote: > > > > > On Sat, May 02, 2020 at 04:58:43PM +0200, Alex Hall wrote: > > > > > > > I didn't think carefully about this

[Python-ideas] Re: zip(x, y, z, strict=True)

On Tue, May 5, 2020 at 5:11 AM Alex Hall wrote: > > On Mon, May 4, 2020 at 1:59 AM Steven D'Aprano wrote: >> Can we agree to meet half-way? >> >> - there are legitimate, genuine uses for zip_strict; >> >> - but encouraging people to change zip to zip_strict "just in case" >> in the absence of

[Python-ideas] Re: zip(x, y, z, strict=True)

On Mon, May 4, 2020 at 1:59 AM Steven D'Aprano wrote: > On Sat, May 02, 2020 at 10:26:18PM +0200, Alex Hall wrote: > > > > If I know that consumers of my data truncate on the shortest input, > then > > > as the producer of data I don't have to care about making them equal. I > > > can say: > > >

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sun, May 03, 2020 at 11:13:58PM -0400, David Mertz wrote: > It seems to me that a Python implementation of zip_equals() shouldn't do > the check in a loop like a version shows (I guess from more-itertools). > More obvious is the following, and this has only a small constant speed > penalty. >

[Python-ideas] Re: zip(x, y, z, strict=True)

Oops. I don't mean any(), but rather 'not all()'. Or alternatively, != instead of ==. Same point though. On Sun, May 3, 2020, 11:13 PM David Mertz wrote: > > Here is a comparison of the current zip with more-itertools' zip_equal: > >> > So the Python version is about 13 times slower, and 10

[Python-ideas] Re: zip(x, y, z, strict=True)

One small comment on this part of the thread: Yes, using an API that produces an infinite iterator with a "strict" version of zip() would be, well, bad. But it would fail the very first time it was used. I can't see how encouraging people to use a strict version of zip() would require that folks

[Python-ideas] Re: zip(x, y, z, strict=True)

> Here is a comparison of the current zip with more-itertools' zip_equal: > > So the Python version is about 13 times slower, and 10 million iterations > > (quite plausible) adds about 2 seconds. > > Adds two seconds to *what* though? That's why I care more about > benchmarks than micro

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sat, May 02, 2020 at 07:43:44PM +0200, Alex Hall wrote: > On Sat, May 2, 2020 at 6:09 PM Steven D'Aprano wrote: > > > On Sat, May 02, 2020 at 04:58:43PM +0200, Alex Hall wrote: > > > > > I didn't think carefully about this implementation and thought that there > > > was only a performance

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sat, May 02, 2020 at 02:58:57PM +0200, Alex Hall wrote: > I'm not sure what the point of this long spiel about floats and str.upper > was. Half a dozen short paragraphs is a long spiel? Sorry, this isn't Twitter, and sorry for not discussing complicated technical debates using a maximum of

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sat, May 02, 2020 at 10:26:18PM +0200, Alex Hall wrote: > > If I know that consumers of my data truncate on the shortest input, then > > as the producer of data I don't have to care about making them equal. I > > can say: > > > > process_user_ids(usernames, generate_user_ids()) > > > > and

[Python-ideas] Re: zip(x, y, z, strict=True)

Steven D'Aprano wrote: > I cannot imagine why you were surprised about that. Did you already forget > about the experience of dict union operators? :-) Well, those were dictionary operators, not zip iterator constructors. ;) > Maybe you should chat with another core developer who *disagrees*

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sat, 2 May 2020 at 12:19, Steven D'Aprano wrote: > - Is there a need for it? Granted. > - Is it complicated to get right? No. This one, I'll query. Until someone (probably you) mentioned it, I didn't think of using zip_longest to do this - probably because I was locked into thinking about the

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sat, May 2, 2020 at 5:10 PM Steven D'Aprano wrote: > On Sat, May 02, 2020 at 02:58:57PM +0200, Alex Hall wrote: > > > Adding a function to itertools will mostly solve that problem, but not > > entirely. Adding `strict=True` is so easy that people will be encouraged > to > > use it often and

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sat, May 2, 2020 at 6:09 PM Steven D'Aprano wrote: > On Sat, May 02, 2020 at 04:58:43PM +0200, Alex Hall wrote: > > > I didn't think carefully about this implementation and thought that there > > was only a performance cost in the error case. That's obviously not true > - > > there's an `if`

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sat, May 02, 2020 at 04:58:43PM +0200, Alex Hall wrote: > I didn't think carefully about this implementation and thought that there > was only a performance cost in the error case. That's obviously not true - > there's an `if` statement executed in Python for every item in every > iterable.

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sat, May 02, 2020 at 02:58:57PM +0200, Alex Hall wrote: > Adding a function to itertools will mostly solve that problem, but not > entirely. Adding `strict=True` is so easy that people will be encouraged to > use it often and keep their code safe. That to me is the biggest argument > for this

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sat, May 2, 2020 at 2:58 PM Alex Hall wrote: > On Sat, May 2, 2020 at 1:19 PM Steven D'Aprano > wrote: > >> Rolling your own on top of >> > zip_longest is easy. It's half a dozen lines. It could be a recipe in >> itertools, or a function. > > >> It has taken years for it to be added to

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sat, May 02, 2020 at 04:40:49PM +0200, Alex Hall wrote: > On Sat, May 2, 2020 at 4:34 PM Steven D'Aprano wrote: > > > On Sat, May 02, 2020 at 02:58:57PM +0200, Alex Hall wrote: > > > > > > > > Yes? Is it our responsibility to put everything in builtins because > > > > people might not think

[Python-ideas] Re: zip(x, y, z, strict=True)

On 5/2/2020 10:40 AM, Alex Hall wrote: On Sat, May 2, 2020 at 4:34 PM Steven D'Aprano > wrote: On Sat, May 02, 2020 at 02:58:57PM +0200, Alex Hall wrote: > > Yes? Is it our responsibility to put everything in builtins because > > people might not

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sat, May 2, 2020 at 4:34 PM Steven D'Aprano wrote: > On Sat, May 02, 2020 at 02:58:57PM +0200, Alex Hall wrote: > > > > > Yes? Is it our responsibility to put everything in builtins because > > > people might not think to look in math, or functools, or os, or sys? > > > > > > > Putting

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sat, May 02, 2020 at 02:58:57PM +0200, Alex Hall wrote: > > Yes? Is it our responsibility to put everything in builtins because > > people might not think to look in math, or functools, or os, or sys? > > > > Putting math.sin or whatever in builtins makes builtins bigger. Adding a > flag to

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sat, May 2, 2020 at 1:19 PM Steven D'Aprano wrote: > But I question whether *enough* people need it *often enough* to make it > a builtin, or to put a flag on plain zip. > It has taken years for it to be added to more-itertools, suggesting that > the real world need for this is small. >

[Python-ideas] Re: zip(x, y, z, strict=True)

That was a good email Alex. Besides the relevant examples, you've put into words things that I wanted to say but didn't realize it. Good job :) On Sat, May 2, 2020 at 4:00 PM Alex Hall wrote: > On Sat, May 2, 2020 at 1:19 PM Steven D'Aprano > wrote: > >> On Sat, May 02, 2020 at 09:54:46AM

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sat, May 2, 2020 at 1:19 PM Steven D'Aprano wrote: > On Sat, May 02, 2020 at 09:54:46AM +0200, Alex Hall wrote: > > > I would say that in pretty much all cases you wouldn't catch the > exception. > > It's the producer's responsibility to produce correct inputs, and if they > > don't, tell

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sat, May 02, 2020 at 09:54:46AM +0200, Alex Hall wrote: > I would say that in pretty much all cases you wouldn't catch the exception. > It's the producer's responsibility to produce correct inputs, and if they > don't, tell them that they failed in their responsibility. > > The underlying

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sat, May 2, 2020 at 3:50 AM Steven D'Aprano wrote: > On Thu, Apr 30, 2020 at 07:58:16AM -0700, Christopher Barker wrote: > > > Imagine someone that uses zip() in code that works for a while, and then > > discovers a bug triggered by unequal length inputs. > > > > If it’s a flag, they look at

[Python-ideas] Re: zip(x, y, z, strict=True)

On Thu, Apr 30, 2020 at 07:58:16AM -0700, Christopher Barker wrote: > Imagine someone that uses zip() in code that works for a while, and then > discovers a bug triggered by unequal length inputs. > > If it’s a flag, they look at the zip docstring, and find the flag, and > their problem is

[Python-ideas] Re: zip(x, y, z, strict=True)

On Tue, Apr 28, 2020 at 02:46:35PM -, Brandt Bucher wrote: > Over the course of the last week, it has become surprisingly clear > that this change is controversial enough to require a PEP. I cannot imagine why you were surprised about that. Did you already forget about the experience of

[Python-ideas] Re: zip(x, y, z, strict=True)

On May 1, 2020, at 08:08, Christopher Barker wrote: > > Also please keep in mind that the members of this list, and the python-dev > list, are not representative of most Python users. Certainly not beginners > but also many (most?) fairly active, but more "casual" users. > > Folks on this

[Python-ideas] Re: zip(x, y, z, strict=True)

It's all been said. There is a PEP being written, so we should all make sure our arguments are well represented there, and let the decision be made. But in all the discussion about usability and discoverability, etc, please keep in mind that zip() is a builtin, and zip_longest() and any other

[Python-ideas] Re: zip(x, y, z, strict=True)

On Apr 29, 2020, at 22:50, Stephen J. Turnbull wrote: > Andrew Barnert via Python-ideas writes: > >>> Also -1 on the flag. > > Also -1 on the flag, for the same set of reasons. > > I have to dissent somewhat from one of the complaints, though: > >> auto-complete won’t help at all, Thanks

[Python-ideas] Re: zip(x, y, z, strict=True)

On 1/05/20 2:58 am, Christopher Barker wrote: Imagine someone that uses zip() in code that works for a while, and then discovers a bug triggered by unequal length inputs. If it’s a flag, they look at the zip docstring, and find the flag, and their problem is solved. Why would they look at

[Python-ideas] Re: zip(x, y, z, strict=True)

On Apr 30, 2020, at 07:58, Christopher Barker wrote: > >> I think that the issue of searchability and signature are pretty >> compelling reasons for such a simple feature to be part of the >> function name. > > I would absolutely agree with that if all three function were in the same >

[Python-ideas] Re: zip(x, y, z, strict=True)

On 2020-04-30 1:07 p.m., Ethan Furman wrote: On 04/30/2020 07:58 AM, Christopher Barker wrote: On 04/29/2020 10:51 PM, Stephen J. Turnbull wrote: I think that the issue of searchability and signature are pretty compelling reasons for such a simple feature to be part of the function name.

[Python-ideas] Re: zip(x, y, z, strict=True)

On 04/30/2020 07:58 AM, Christopher Barker wrote: On 04/29/2020 10:51 PM, Stephen J. Turnbull wrote: I think that the issue of searchability and signature are pretty compelling reasons for such a simple feature to be part of the function name. I would absolutely agree with that if all three

[Python-ideas] Re: zip(x, y, z, strict=True)

> I think that the issue of searchability and signature are pretty > compelling reasons for such a simple feature to be part of the > function name. I would absolutely agree with that if all three function were in the same namespace (like the string methods referred to earlier), but in this

[Python-ideas] Re: zip(x, y, z, strict=True)

Andrew Barnert via Python-ideas writes: > > Also -1 on the flag. Also -1 on the flag, for the same set of reasons. I have to dissent somewhat from one of the complaints, though: > auto-complete won’t help at all, Many (most?) people use IDEs that will catch up more or less quickly, though.

[Python-ideas] Re: zip(x, y, z, strict=True)

On Apr 29, 2020, at 07:08, Barry Scott wrote: > > >> On 28 Apr 2020, at 16:12, Rhodri James wrote: >> >>> On 28/04/2020 15:46, Brandt Bucher wrote: >>> Thanks for weighing in, everybody. >>> Over the course of the last week, it has become surprisingly clear that >>> this change is

[Python-ideas] Re: zip(x, y, z, strict=True)

On Tue, Apr 28, 2020 at 7:49 AM Brandt Bucher wrote: > With that in mind, I've started drafting one summarizing the discussion > that took place here, and arguing for the addition of a boolean flag to the > `zip` constructor. Since you've gotten a few -1s, I'll add a +1 -- for reasons posted

[Python-ideas] Re: zip(x, y, z, strict=True)

> On 28 Apr 2020, at 16:12, Rhodri James wrote: > > On 28/04/2020 15:46, Brandt Bucher wrote: >> Thanks for weighing in, everybody. >> Over the course of the last week, it has become surprisingly clear that this >> change is controversial enough to require a PEP. >> With that in mind, I've

[Python-ideas] Re: zip(x, y, z, strict=True)

On 28/04/2020 15:46, Brandt Bucher wrote: Thanks for weighing in, everybody. Over the course of the last week, it has become surprisingly clear that this change is controversial enough to require a PEP. With that in mind, I've started drafting one summarizing the discussion that took place

[Python-ideas] Re: zip(x, y, z, strict=True)

Thanks for weighing in, everybody. Over the course of the last week, it has become surprisingly clear that this change is controversial enough to require a PEP. With that in mind, I've started drafting one summarizing the discussion that took place here, and arguing for the addition of a

[Python-ideas] Re: zip(x, y, z, strict=True)

On Mon, Apr 27, 2020 at 09:21:41AM -0700, Andrew Barnert wrote: > But this doesn’t do what the OP suggested; it’s a completely different > proposal. They wanted to write this: > > zipped = zip(xs, ys).skip() > > … and you’re offering this: > > zipped = zip.skip(xs, ys) > > That’s a

[Python-ideas] Re: zip(x, y, z, strict=True)

On Mon, Apr 27, 2020 at 4:39 PM Christopher Barker wrote: > Isn't there? There are many cases where you CANNOT (or don't want to, for > performance reasons) "consume" the entirely of the inolut iterators, and > many cases where it would be fine to do that. But are there many (any?) > cases where

[Python-ideas] Re: zip(x, y, z, strict=True)

On 27/04/2020 21:39, Christopher Barker wrote: To me, having a zip_equal that iterates through the inputs on demand, and checks when one is exhausted, rather than pre-determining the lengths ahead of time will solve almost all (or all? I can't think of an example where it wouldn't) use cases

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sun, Apr 26, 2020 at 9:21 PM David Mertz wrote: > On Sun, Apr 26, 2020 at 11:56 PM Christopher Barker > wrote: > >> > If I have two or more "sequences" there are basically two cases of that. >> >> so you need to write different code, depending on which case? that seems >> not very "there's

[Python-ideas] Re: zip(x, y, z, strict=True)

On Apr 26, 2020, at 21:23, David Mertz wrote: > >  >> On Sun, Apr 26, 2020 at 11:56 PM Christopher Barker >> wrote: >> > If I have two or more "sequences" there are basically two cases of that. >> >> so you need to write different code, depending on which case? that seems not >> very

[Python-ideas] Re: zip(x, y, z, strict=True)

On Apr 26, 2020, at 16:58, Steven D'Aprano wrote: > > On Sun, Apr 26, 2020 at 04:13:27PM -0700, Andrew Barnert via Python-ideas > wrote: > >> But if we add methods on zip objects, and then we add a new skip() >> method in 3.10, how does the backport work? It can’t monkeypatch the >> zip

[Python-ideas] Re: zip(x, y, z, strict=True)

On 04/26/2020 08:56 PM, Christopher Barker wrote: that seems not very "there's only one way to do it" to me. The quote is "one obvious way". It almost feels like the proponents of the new mode/function are hoping to avoid the processing that might need to be "rolled back" in some manner

[Python-ideas] Re: zip(x, y, z, strict=True)

Here's an idea for combining zip_longest with zip strict. Define zip like so: def zip(*iterables, strict=False, fill=object()) With no arguments, it's the regular old zip. With `strict=True`, it ensures the iterators are equal. If you pass in an argument for `fill`, it becomes zip_longest. On

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sun, Apr 26, 2020 at 11:56 PM Christopher Barker wrote: > > If I have two or more "sequences" there are basically two cases of that. > > so you need to write different code, depending on which case? that seems > not very "there's only one way to do it" to me. > This difference is built into

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sun, Apr 26, 2020 at 10:52 AM David Mertz wrote: > Let me try to explain why I believe that people who think they want > zip_strict() actually want zip_longest(). > Thanks for laying it out so clearly. However, reading your post makes it clear to me that I DO still want zip_strict() :-) It

[Python-ideas] Re: zip(x, y, z, strict=True)

On Mon, Apr 27, 2020 at 9:57 AM Steven D'Aprano wrote: > I don't especially want zip_whatever to be slow, but the stdlib has > no obligation to provide a super-fast highly optimized C accelerated > version of **everything**. Especially not backports. It is perfectly > acceptable to say: > >

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sun, Apr 26, 2020 at 04:13:27PM -0700, Andrew Barnert via Python-ideas wrote: > But if we add methods on zip objects, and then we add a new skip() > method in 3.10, how does the backport work? It can’t monkeypatch the > zip type (unless we both make the type public and specifically design >

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sun, Apr 26, 2020 at 10:34:27PM +0100, Daniel Moisset wrote: >- we could add methods to the zip() type that provide different >behaviours. That way you could use zip(seq, seq2).shortest(), zip(seq1, >seq2).equal(), zip(seq1, seq2).longer(filler="foo") ; zip(...).shortest() >

[Python-ideas] Re: zip(x, y, z, strict=True)

On Apr 26, 2020, at 14:36, Daniel Moisset wrote: > > This idea is something I could have used many times. I agree with many people > here that the strict=True API is at least "unusual" in Python. I was thinking > of 2 different API approaches that could be used for this and I think no one >

[Python-ideas] Re: zip(x, y, z, strict=True)

This idea is something I could have used many times. I agree with many people here that the strict=True API is at least "unusual" in Python. I was thinking of 2 different API approaches that could be used for this and I think no one has mentioned: - we could add a callable filler_factory

[Python-ideas] Re: zip(x, y, z, strict=True)

Let me try to explain why I believe that people who think they want zip_strict() actually want zip_longest(). I've already mentioned that I myself usually want what zip() does not (i.e. zip_shortest()) ... but indeed not always. If I have two or more "sequences" there are basically two cases of

  1   2   >