[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: Equality between some of the indexed collections

Thanks, I do appreciate all the discussion here about that. Initially, I was thinking about having lists/arrays/tuples match the behavior of other instances in python that compare across their types like: 1) Sets (instances of set or frozenset) can be compared within and across their types As Do

[Python-ideas] Re: Equality between some of the indexed collections

On 5/3/20 8:40 AM, Ahmed Amr wrote: > Thanks, I do appreciate all the discussion here about that. > > Initially, I was thinking about having lists/arrays/tuples match the behavior > of other instances in python that compare across their types like: > 1) Sets (instances of set or frozenset) can be

[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* wit

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

If `zip` gets a `strict` keyword-only parameter, a slightly related question is whether `map` should also receive one? `map` can be used as zip + transform:     map(func, x, y)     (func(a, b) for a, b in zip(x, y))  # similar Now if I'm using the first option and I want to enable the strict ch

[Python-ideas] PEP 472 -- Support for indexing with keyword arguments

Hello! I'm not sure I'm addressing the right audience here, so please direct me to the appropriate channel if that's the case... My name is Andras Tantos and I'm working on a Python library desscribing HW designs. I came across this problem of __getitem__ and co. not supporting kwargs. Appar

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

On Sun, May 3, 2020 at 3:39 PM Dominik Vilsmeier wrote: > If `zip` gets a `strict` keyword-only parameter, a slightly related > question is whether `map` should also receive one? > This did come up in the conversion. Brandt: you may want to address this in the PEP. map(func, x, y, strict=T

[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)

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 1

[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 cost

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

On Sun, May 03, 2020 at 04:09:21PM -0700, Christopher Barker wrote: > > map(func, x, y, strict=True) # ? > > > > Admittedly the word "strict" in the context of `map` would be rather > > confusing. > > > > This a really good argument for "equal" rather than "strict". Sorry, I'm not seeing wh

[Python-ideas] Re: Equality between some of the indexed collections

On Sat, May 02, 2020 at 11:01:21PM +0200, Alex Hall wrote: > On Sat, May 2, 2020 at 10:52 PM Dominik Vilsmeier > wrote: > > > `frozenset` and `set` make a counterexample: > > > > >>> frozenset({1}) == {1} > > True > > > > Nice catch! That's really interesting. Is there reasoning behind > `frozen

[Python-ideas] Re: Equality between some of the indexed collections

On 2020-05-03 10:19 p.m., Steven D'Aprano wrote: On Sat, May 02, 2020 at 11:01:21PM +0200, Alex Hall wrote: > On Sat, May 2, 2020 at 10:52 PM Dominik Vilsmeier > wrote: > > > `frozenset` and `set` make a counterexample: > > > > >>> frozenset({1}) == {1} > > True > > > > Nice catch! That's

[Python-ideas] Re: Equality between some of the indexed collections

On Mon, May 4, 2020 at 11:43 AM Soni L. wrote: > > > > On 2020-05-03 10:19 p.m., Steven D'Aprano wrote: > > On Sat, May 02, 2020 at 11:01:21PM +0200, Alex Hall wrote: > > > On Sat, May 2, 2020 at 10:52 PM Dominik Vilsmeier > > > > > > wrote: > > > > > > > `frozenset` and `set` make a counterexam

[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 benchmarks

[Python-ideas] PEP 597 -- Soft deprecation of omitting encoding

The PEP is here: https://www.python.org/dev/peps/pep-0597/ I created a thread on discuss.python.org but I want more feedback. Please reply on this mail or discuss.python.org. ## Summary This PEP doesn't propose t

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

On Sun, May 3, 2020 at 6:17 PM Steven D'Aprano wrote: > > > map(func, x, y, strict=True) # ? > > > > > > Admittedly the word "strict" in the context of `map` would be rather > > > confusing. > > > > > > > This a really good argument for "equal" rather than "strict". > > Sorry, I'm not seeing

[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: PEP 618: Add Optional Length-Checking To zip

I should really stay out of this (hundreds of messages and still bickering^Wbikeshedding :-), but I personally find strict=True *less* confusing than equal=True, both for zip() and for map(). If I didn't know what was going on, seeing equal=True would make me wonder about whether equality between t

[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 mi