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

I think you misunderstood me - otherwise I don't know what this email is meant to accomplish. The conversation as I see it went: Brandt in the PEP: X is an antipattern. Andrew to Brandt: A strict flag would require us to do Y which you said is an antipattern. Me to Andrew: Y is fine, it's not an a

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

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

I'm +1 obviously :) On Fri, May 1, 2020 at 9:19 PM Brandt Bucher wrote: > I have pushed a first 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! > > Brandt > ___

[Python-ideas] Re: Adding a "once" function to functools

Andrew, can you describe the memory model issue in detail? Regards Antoine. On Fri, 1 May 2020 22:45:13 -0700 Andrew Barnert via Python-ideas wrote: > On May 1, 2020, at 09:51, Tom Forbes wrote: > >  > >> You’ve written an exactly equIvalent to the double-checked locking for > >> singlet

[Python-ideas] Re: Introduce 100 more built-in exceptions

On Fri, 1 May 2020 at 10:29, Steven D'Aprano wrote: [...] > "Is it UnpackingOverflowException or PackingUnderflowError or > TooManyValuesUnpackException or ValueUnpackingError or ...???" > It took me far too long to learn the difference between > UnicodeEncodingError and UnicodeDecodingError. Or

[Python-ideas] Re: Introduce 100 more built-in exceptions

On 5/2/2020 6:00 AM, Henk-Jaap Wagenaar wrote: On Fri, 1 May 2020 at 10:29, Steven D'Aprano > wrote: [...] > "Is it UnpackingOverflowException or PackingUnderflowError or > TooManyValuesUnpackException or ValueUnpackingError or ...???" > It took me far too long to lea

[Python-ideas] Re: Adding a "once" function to functools

> Does that sound good enough to dismiss the problem? Sure, tangibly related issues with other implementations from a discussion in the 00’s doesn’t seem like a fantastic argument, especially given that we use this exact pattern already in the stdlib without issue: https://github.com/python/cpy

[Python-ideas] Re: Introduce 100 more built-in exceptions

Of course, there are other ways of writing this code, but imagine this for a database interface where a save normally returns the saved object (inspired by Django) ``` try: x, y = Foo.save() except ValueUnpackingError: // oh... this means saving failed (it returned None instead) // let

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

[Python-ideas] Re: Introduce 100 more built-in exceptions

On Sat, May 2, 2020 at 12:39 PM Henk-Jaap Wagenaar < [email protected]> wrote: > Of course, there are other ways of writing this code, but imagine this for > a database interface where a save normally returns the saved object > (inspired by Django) > > ``` > try: > x, y = Foo.save() >

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

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

I'd like to take your opinion on modifying some of the indexed collections like tuples, lists, arrays to evaluate its equality to True when having the same items in the same indexes. Currently, when comparing a list of items to an array of the same items for equality (==) it returns False, I'm

[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 +0200

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

Hi I've read some posts on this topic, but this is my first contribution.Thank you Brandt for writing the PEP. I like it's clarity. And thank you Ram for making the suggestion that started the discussion. I fully agree, that we have here a problem worth solving. And many thanks for the many other

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

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 z

[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 math.si

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

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

You can get the desired behavior by casting a list to a tuple, or a tuple to a list, in the equality statement. That way those that rely on the existing implementation don't have to change their code. my_tup = (1, 2, 3) my_list = [1, 2, 3] print(list(my_tup) == my_list) On Sat, May 2, 2020, 9:04

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

[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 more-i

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

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

This is how it looks for me in the text part of the email: On Sat, May 02, 2020 at 02:58:57PM +0200, Alex Hall wrote: > Putting math.sin or whatever in builtins makes builtins bigger. Adding a > flag to zip does not. > > I think I've missed what harm you t

[Python-ideas] Re: Introduce 100 more built-in exceptions

On 5/2/2020 7:18 AM, Alex Hall wrote: On Sat, May 2, 2020 at 12:39 PM Henk-Jaap Wagenaar mailto:[email protected]>> wrote: Of course, there are other ways of writing this code, but imagine this for a database interface where a save normally returns the saved object (inspire

[Python-ideas] Re: Introduce 100 more built-in exceptions

On 2020-05-02 11:59 a.m., Eric V. Smith wrote: On 5/2/2020 7:18 AM, Alex Hall wrote: On Sat, May 2, 2020 at 12:39 PM Henk-Jaap Wagenaar mailto:[email protected]>> wrote: Of course, there are other ways of writing this code, but imagine this for a database interface where a s

[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. S

[Python-ideas] Re: Introduce 100 more built-in exceptions

On Sat, May 02, 2020 at 12:50:19PM -0300, Soni L. wrote: > how about: > > result = Foo.save() > try: >   x, y = result > except ValueUnpackingError: >   return ... If you do that, what benefit is ValueUnpackingError over just ValueError? -- Steven ___

[Python-ideas] Re: Introduce 100 more built-in exceptions

On 2020-05-02 1:07 p.m., Steven D'Aprano wrote: On Sat, May 02, 2020 at 12:50:19PM -0300, Soni L. wrote: > how about: > > result = Foo.save() > try: >   x, y = result > except ValueUnpackingError: >   return ... If you do that, what benefit is ValueUnpackingError over just ValueError? un

[Python-ideas] Re: Introduce 100 more built-in exceptions

On 5/2/2020 12:20 PM, Soni L. wrote: On 2020-05-02 1:07 p.m., Steven D'Aprano wrote: On Sat, May 02, 2020 at 12:50:19PM -0300, Soni L. wrote: > how about: > > result = Foo.save() > try: >   x, y = result > except ValueUnpackingError: >   return ... If you do that, what benefit is ValueUnpack

[Python-ideas] Re: Introduce 100 more built-in exceptions

On Sat, May 02, 2020 at 01:20:01PM -0300, Soni L. wrote: > > > On 2020-05-02 1:07 p.m., Steven D'Aprano wrote: > >On Sat, May 02, 2020 at 12:50:19PM -0300, Soni L. wrote: > > > >> how about: > >> > >> result = Foo.save() > >> try: > >>   x, y = result > >> except ValueUnpackingError: > >>   retu

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

(and a check on the length or zip_longest to ensure that there is no other items) Le sam. 2 mai 2020 à 18:53, Antoine Rozo a écrit : > > And if you can't / don't want to create new lists for the values you > want to compare, a solution could be to use zip & all builtins: > > print(all(a == b for

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

And if you can't / don't want to create new lists for the values you want to compare, a solution could be to use zip & all builtins: print(all(a == b for a, b in zip(tuple_, list_))) Le sam. 2 mai 2020 à 16:58, Steele Farnsworth a écrit : > > You can get the desired behavior by casting a list to

[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` s

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

I see there are ways to compare them item-wise, I'm suggesting to bake that functionality inside the core implementation of such indexed structures. Also those solutions are direct with tuples and lists, but it wouldn't be as direct with arrays-lists/tuples comparisons for example. On Sat, 2 May 2

[Python-ideas] Re: Introduce 100 more built-in exceptions

On 2020-05-02 1:45 p.m., Steven D'Aprano wrote: On Sat, May 02, 2020 at 01:20:01PM -0300, Soni L. wrote: > > > On 2020-05-02 1:07 p.m., Steven D'Aprano wrote: > >On Sat, May 02, 2020 at 12:50:19PM -0300, Soni L. wrote: > > > >> how about: > >> > >> result = Foo.save() > >> try: > >>   x, y

[Python-ideas] Re: Introduce 100 more built-in exceptions

On 5/2/2020 2:39 PM, Soni L. wrote: On 2020-05-02 1:45 p.m., Steven D'Aprano wrote: On Sat, May 02, 2020 at 01:20:01PM -0300, Soni L. wrote: > > > On 2020-05-02 1:07 p.m., Steven D'Aprano wrote: > >On Sat, May 02, 2020 at 12:50:19PM -0300, Soni L. wrote: > > > >> how about: > >> > >> result =

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

Put this comparison in a function! The current behavior is what I wish '==' to do, and what millions of lines of Python code assume. A tuple is not a list is not an array. I don't want an equality comparison to lie to me. You can write a few lines to implement 'has_same_items(a, b)' that will beha

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

On Sat, May 2, 2020 at 8:38 PM Ahmed Amr wrote: > I see there are ways to compare them item-wise, I'm suggesting to bake > that functionality inside the core implementation of such indexed > structures. > I'm sure there are times when I would also like this, and others too. But it would be a dis

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

02.05.20 21:34, Ahmed Amr пише: I see there are ways to compare them item-wise, I'm suggesting to bake that functionality inside the core implementation of such indexed structures. Also those solutions are direct with tuples and lists, but it wouldn't be as direct with arrays-lists/tuples compa

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

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

On Sat, May 2, 2020 at 9:51 PM Serhiy Storchaka wrote: > 02.05.20 21:34, Ahmed Amr пише: > > I see there are ways to compare them item-wise, I'm suggesting to bake > > that functionality inside the core implementation of such indexed > > structures. > > Also those solutions are direct with tuples

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

It does look like that would violate a basic property of `==` -- if two values compare equal, they should be equally usable as dict keys. I can't think of any counterexamples. On Sat, May 2, 2020 at 1:33 PM Alex Hall wrote: > On Sat, May 2, 2020 at 9:51 PM Serhiy Storchaka > wrote: > >> 02.05.2

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

`frozenset` and `set` make a counterexample: >>> frozenset({1}) == {1} True On 02.05.20 22:36, Guido van Rossum wrote: It does look like that would violate a basic property of `==` -- if two values compare equal, they should be equally usable as dict keys. I can't think of any counterexamples.

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

Okay, that's fair. So the argument really comes down to backwards compatibility (which is inconvenient but important). On Sat, May 2, 2020 at 1:51 PM Dominik Vilsmeier wrote: > `frozenset` and `set` make a counterexample: > > >>> frozenset({1}) == {1} > True > On 02.05.20 22:36, Guido van Rossum

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

On Sat, May 2, 2020 at 10:36 PM Guido van Rossum wrote: > It does look like that would violate a basic property of `==` -- if two > values compare equal, they should be equally usable as dict keys. > It's certainly a reasonable property, but I don't think it's critical. By comparison, if it was

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

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 `frozenset({1}) == {1}` but `[1] != (1,)`, or is it just an accident of history? Isn't a

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

02.05.20 23:32, Alex Hall пише: On Sat, May 2, 2020 at 9:51 PM Serhiy Storchaka > wrote: 02.05.20 21:34, Ahmed Amr пише: > I see there are ways to compare them item-wise, I'm suggesting to bake > that functionality inside the core implementation of s

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

On 5/2/20 5:13 PM, Serhiy Storchaka wrote: > 02.05.20 23:32, Alex Hall пише: >> On Sat, May 2, 2020 at 9:51 PM Serhiy Storchaka > > wrote: >>     02.05.20 21:34, Ahmed Amr пише: >> > I see there are ways to compare them item-wise, I'm suggesting to >>     bake >>   

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

Thanks Brandt for writting this up. A few notes: 1) already said, but it struck me when I say it: "with nobody challenging the use of the word "strict": A number of us have expressed an preference for "equal" over "strict". 2) "Add Additional Flavors Of zip To itertools" -- I think you're going t

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

On Sat, May 2, 2020 at 11:39 PM Richard Damon wrote: > Doesn't it also imply that ('a',) == 'a' and that you couldn't get a > dict to use both of these as keys? > ``` >>> {1.0: 2, 1: 3} {1.0: 3} ``` ___ Python-ideas mailing list -- python-ideas@python.

[Python-ideas] Re: Introduce 100 more built-in exceptions

On Sat, May 02, 2020 at 03:39:50PM -0300, Soni L. wrote: > def foo(): >   yield from () >   raise ValueError def foo(): yield from ()   raise ValueUnpackingError Does that help? -- Steven ___ Python-ideas mailing list -- python-ide

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

On 5/2/2020 6:03 PM, Alex Hall wrote: On Sat, May 2, 2020 at 11:39 PM Richard Damon mailto:[email protected]>> wrote: Doesn't it also imply that ('a',) == 'a' and that you couldn't get a dict to use both of these as keys? ``` >>> {1.0: 2, 1: 3} {1.0: 3} ``` I think the implic

[Python-ideas] Re: Introduce 100 more built-in exceptions

On 2020-05-02 7:29 p.m., Steven D'Aprano wrote: On Sat, May 02, 2020 at 03:39:50PM -0300, Soni L. wrote: > def foo(): >   yield from () >   raise ValueError def foo(): yield from ()   raise ValueUnpackingError Does that help? the idea is that it'd become a RuntimeErro