[Python-ideas] Re: zip should return partial results in StopIteration

On 22/04/20 3:15 am, Chris Angelico wrote: Currently, it retains any value that was already in it - so if the shortest iterable is a generator, then its return value will be in the propagated StopIteration. Not sure if that's a guarantee and therefore covered by backward compatibility. I don't

[Python-ideas] Re: zip should return partial results in StopIteration

On 2020-04-21 7:12 p.m., Steven D'Aprano wrote: On Tue, Apr 21, 2020 at 05:33:24PM -0300, Soni L. wrote: > 1. see the other thread (strict zip), especially the parts where they > brought up the lack of peekable/unput iterators in the context of > getting a count out of an iterator. I've

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

On Wed, Apr 22, 2020 at 01:07:07AM +0200, Antoine Pitrou wrote: > On Wed, 22 Apr 2020 08:34:56 +1000 > Steven D'Aprano wrote: > > On Tue, Apr 21, 2020 at 12:09:44PM +0300, Serhiy Storchaka wrote: > > > 21.04.20 11:15, Antoine Pitrou пише: > > > >Of course, the fact that zip() is the shorter

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

On Mon, Apr 20, 2020 at 07:47:51PM -0700, Andrew Barnert wrote: > >> counter = itertools.count() > >> yield from zip(counter, itertools.chain(headers, [''], body, ['']) > >> lines = next(counter) > > > > That gives you one more than the number of lines yielded. > > Yeah, I screwed that up in

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

On 4/21/2020 7:07 PM, Antoine Pitrou wrote: On Wed, 22 Apr 2020 08:34:56 +1000 Steven D'Aprano wrote: On Tue, Apr 21, 2020 at 12:09:44PM +0300, Serhiy Storchaka wrote: 21.04.20 11:15, Antoine Pitrou пише: Of course, the fact that zip() is the shorter form that everyone is used to means that,

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

On Tue, Apr 21, 2020 at 02:33:04PM -, Brandt Bucher wrote: > > Sure, but I think cases where you want that assumption _checked_ are a lot > > less common. There are lots of postconditions that you assume just as often > > as “x, y, and z are fully consumed” and just as rarely want to check,

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

On Wed, 22 Apr 2020 08:34:56 +1000 Steven D'Aprano wrote: > On Tue, Apr 21, 2020 at 12:09:44PM +0300, Serhiy Storchaka wrote: > > 21.04.20 11:15, Antoine Pitrou пише: > > >Of course, the fact that zip() is the shorter form that everyone is > > >used to means that, even if a `strict` argument is

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

On Tue, Apr 21, 2020 at 12:25:06PM -0700, Andrew Barnert via Python-ideas wrote: > On Apr 21, 2020, at 01:36, Serhiy Storchaka wrote: > > > >except ValueError: # assuming that’s the exception you want? > > For what it’s worth, more_itertools.zip_equal raises an > UnequalIterablesError,

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

On Tue, Apr 21, 2020 at 12:09:44PM +0300, Serhiy Storchaka wrote: > 21.04.20 11:15, Antoine Pitrou пише: > >Of course, the fact that zip() is the shorter form that everyone is > >used to means that, even if a `strict` argument is added, few people > >will bother adding it. > > The possible

[Python-ideas] Re: zip should return partial results in StopIteration

On Wed, Apr 22, 2020 at 8:20 AM Steven D'Aprano wrote: > > On Wed, Apr 22, 2020 at 01:25:14AM +1000, Chris Angelico wrote: > > > That'd make it show up as the exception's 'value', not in its args. If > > indeed there's no guarantee, then I would fully support this change - > > should be a

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

> Have you written your own version that does this check for input iterable > equality? No, unfortunately. As I've mentioned before, it just feels too heavy to wrap all of these nice builtin zip objects to check things that "must" be true. If this option were available, I would certainly

[Python-ideas] Re: zip should return partial results in StopIteration

On Wed, Apr 22, 2020 at 01:25:14AM +1000, Chris Angelico wrote: > That'd make it show up as the exception's 'value', not in its args. If > indeed there's no guarantee, then I would fully support this change - > should be a non-breaking change and could be convenient. Convenient for what? --

[Python-ideas] Re: zip should return partial results in StopIteration

On Tue, Apr 21, 2020 at 05:33:24PM -0300, Soni L. wrote: > 1. see the other thread (strict zip), especially the parts where they > brought up the lack of peekable/unput iterators in the context of > getting a count out of an iterator. I've seen it, as far as I can tell there are already good

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

On 04/21/2020 07:33 AM, Brandt Bucher wrote: I know that I, and everyone on my team, would use it frequently! Have you written your own version that does this check for input iterable equality? -- ~Ethan~ ___ Python-ideas mailing list --

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

On 04/21/2020 12:58 PM, David Mertz wrote: >>> it1 = iter([1,2,3]) >>> it2 = iter([4,5]) >>> it3 = iter([6,7,8, 9]) >>> list(zip(it1, it2, it3)) [(1, 4, 6), (2, 5, 7)] next(it3) 8 [...] worse is that most versions being discussed here seem to consume the 8 from it3 before raising the

[Python-ideas] Re: zip should return partial results in StopIteration

On 2020-04-21 12:48 p.m., Serhiy Storchaka wrote: 21.04.20 17:10, Soni L. пише: I feel like zip could return partial results: try:    next(zip([0], [])) except StopIteration as exc:    assert StopIteration.args == (0,) how much would this break? Why do you need this feature? 3 reasons:

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

> But it's not a big distinction, merely one of intent. And as yet, the person > who claimed that wanting an exception from zip was an overwhelmingly common > case for them hasn't replied yet to my question - so I may be completely > wrong. Well, hopefully I get more than 2 working hours to

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

The more I read the discussion, the more zip_strict() feels like an anti-pattern to me. I've used zip_longest occasionally, but never really hit a need for zip_strict() ... which obviously I could have written in a few lines if I wanted it. Since I never know how many elements an iterator has

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

On Apr 21, 2020, at 01:36, Serhiy Storchaka wrote: > >except ValueError: # assuming that’s the exception you want? For what it’s worth, more_itertools.zip_equal raises an UnequalIterablesError, which is a subclass of ValueError. I’m not sure whether having a special error class is worth

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

On Apr 21, 2020, at 01:36, Serhiy Storchaka wrote: > > 20.04.20 23:33, Andrew Barnert via Python-ideas пише: >> Should this print 1 or 2 or raise StopIteration or be a don’t-care? >> Should it matter if you zip(y, x, strict=True) instead? > > It should print 2 in both cases. The only way to

[Python-ideas] Re: Keyword arguments self-assignment

On Apr 21, 2020, at 01:27, M.-A. Lemburg wrote: > > On 21.04.2020 04:25, Andrew Barnert via Python-ideas wrote: >>> On Apr 20, 2020, at 16:24, M.-A. Lemburg wrote: >>> >>> On 20.04.2020 19:43, Andrew Barnert via Python-ideas wrote: > On Apr 20, 2020, at 01:06, M.-A. Lemburg wrote: >

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

On Tue, 21 Apr 2020 at 17:53, Serhiy Storchaka wrote: > > 21.04.20 19:35, Paul Moore пише: > > Hence my suggestion that maybe it's not so much an > > (actionable) exception that people want as an assertion. > > What do you mean by assertion? Raising an AssertionError? Crashing the > program? See

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

21.04.20 19:35, Paul Moore пише: Hence my suggestion that maybe it's not so much an (actionable) exception that people want as an assertion. What do you mean by assertion? Raising an AssertionError? Crashing the program? ___ Python-ideas mailing

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

On Tue, 21 Apr 2020 at 16:28, Dan Sommers <2qdxy4rzwzuui...@potatochowder.com> wrote: > > On Tue, 21 Apr 2020 16:05:54 +0100 > Paul Moore wrote: > > > To be clear - would you catch the error in your code? What would you > > do when it was raised? Or are you simply wanting, in effect, an assert >

[Python-ideas] Re: zip should return partial results in StopIteration

21.04.20 17:10, Soni L. пише: I feel like zip could return partial results: try:   next(zip([0], [])) except StopIteration as exc:   assert StopIteration.args == (0,) how much would this break? Why do you need this feature? ___ Python-ideas

[Python-ideas] Re: Keyword arguments self-assignment

On Wed, Apr 22, 2020 at 1:38 AM Rhodri James wrote: > > On 21/04/2020 15:29, Chris Angelico wrote: > > On Wed, Apr 22, 2020 at 12:06 AM Eric V. Smith wrote: > >> That's a good example, Chris. Thanks. I also don't see that a namespace > >> object would buy you much, if anything. > >> > >> Going

[Python-ideas] Re: Keyword arguments self-assignment

On 21/04/2020 15:29, Chris Angelico wrote: On Wed, Apr 22, 2020 at 12:06 AM Eric V. Smith wrote: That's a good example, Chris. Thanks. I also don't see that a namespace object would buy you much, if anything. Going with the tersest proposal (twitter=twitter becomes twitter=), we'd save

[Python-ideas] Re: zip should return partial results in StopIteration

On Wed, Apr 22, 2020 at 1:22 AM Soni L. wrote: > looking further into it, zip() already guarantees the StopIteration isn't > gonna preserve the original StopIteration, so this should be a non-breaking > change: > > https://docs.python.org/3/library/functions.html#zip > I'm sorry, I'm not sure

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

On Tue, 21 Apr 2020 16:05:54 +0100 Paul Moore wrote: > To be clear - would you catch the error in your code? What would you > do when it was raised? Or are you simply wanting, in effect, an assert > when some iterables remain unexhausted? Because I can imagine that > wanting builtins to assert

[Python-ideas] Re: zip should return partial results in StopIteration

On Wed, Apr 22, 2020 at 12:25 AM Eric V. Smith wrote: > > On 4/21/2020 10:14 AM, Eric V. Smith wrote: > > On 4/21/2020 10:10 AM, Soni L. wrote: > >> I feel like zip could return partial results: > >> > >> try: > >> next(zip([0], [])) > >> except StopIteration as exc: > >> assert

[Python-ideas] Re: zip should return partial results in StopIteration

On 2020-04-21 12:01 p.m., Soni L. wrote: On 2020-04-21 11:20 a.m., Eric V. Smith wrote: On 4/21/2020 10:14 AM, Eric V. Smith wrote: On 4/21/2020 10:10 AM, Soni L. wrote: I feel like zip could return partial results: try:   next(zip([0], [])) except StopIteration as exc:   assert

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

On Wed, Apr 22, 2020 at 12:47 AM Brandt Bucher wrote: > Unlike some on this thread, I think the default behavior for `zip` is fine. > It's not broken, and it *should* be able to handle infinite iterables by > default. This isn't just a "band-aid" fix; it's a feature that allows many > (if not

[Python-ideas] Re: zip should return partial results in StopIteration

On Tue, 21 Apr 2020 at 15:25, Eric V. Smith wrote: > > In your proposal, what would next(zip([0], [], [0])) result in? > > > This point still stands. ... and for an even more non-obvious case, next(zip(itertools.cycle([0]), [], [0])) (do we just return *one* element that's not been consumed, or

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

On Tue, 21 Apr 2020 at 15:49, Brandt Bucher wrote: > > Of course, the fact that zip() is the shorter form that everyone is used to > > means that, even if a strict argument is added, few people will bother > > adding it. > > I know that I, and everyone on my team, would use it frequently! To

[Python-ideas] Re: zip should return partial results in StopIteration

On 2020-04-21 11:20 a.m., Eric V. Smith wrote: On 4/21/2020 10:14 AM, Eric V. Smith wrote: On 4/21/2020 10:10 AM, Soni L. wrote: I feel like zip could return partial results: try:   next(zip([0], [])) except StopIteration as exc:   assert StopIteration.args == (0,) how much would this

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

> Sure, but I think cases where you want that assumption _checked_ are a lot > less common. There are lots of postconditions that you assume just as often > as “x, y, and z are fully consumed” and just as rarely want to check, so we > don’t need to make it easy to check every possible one of

[Python-ideas] Re: Keyword arguments self-assignment

On Wed, Apr 22, 2020 at 12:06 AM Eric V. Smith wrote: > That's a good example, Chris. Thanks. I also don't see that a namespace > object would buy you much, if anything. > > Going with the tersest proposal (twitter=twitter becomes twitter=), we'd > save something like 40 characters in the

[Python-ideas] Re: zip should return partial results in StopIteration

On 4/21/2020 10:14 AM, Eric V. Smith wrote: On 4/21/2020 10:10 AM, Soni L. wrote: I feel like zip could return partial results: try:   next(zip([0], [])) except StopIteration as exc:   assert StopIteration.args == (0,) how much would this break? It would break a lot of code, and so it won't

[Python-ideas] Re: zip should return partial results in StopIteration

Which of these would you consider correct? try: next(zip([0], [])) except StopIteration as exc: assert StopIteration.args == (0,) vs try: next(zip([], [0])) except StopIteration as exc: assert StopIteration.args == (0,) On Tue, Apr 21, 2020 at 10:14 AM Soni L. wrote: > I feel

[Python-ideas] Re: zip should return partial results in StopIteration

On 4/21/2020 10:10 AM, Soni L. wrote: I feel like zip could return partial results: try:   next(zip([0], [])) except StopIteration as exc:   assert StopIteration.args == (0,) how much would this break? It would break a lot of code, and so it won't happen. You can use itertools.zip_longest

[Python-ideas] zip should return partial results in StopIteration

I feel like zip could return partial results: try:   next(zip([0], [])) except StopIteration as exc:   assert StopIteration.args == (0,) how much would this break? ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email

[Python-ideas] Re: Keyword arguments self-assignment

On 4/21/2020 9:51 AM, Chris Angelico wrote: On Tue, Apr 21, 2020 at 7:01 PM M.-A. Lemburg wrote: Instead of keeping values in local variables, you store them in the namespace object and because this knows about its attributes you can do a lot more in terms of introspection than what is

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Tue, Apr 21, 2020 at 6:56 PM Alex Hall wrote: > > Exposing the AST is probably overkill, but we could probably come up with a > different way to give Python users easy access to the argument names. For > example, suppose you could define functions like this: > > ``` > foo = 1 > bar = 2 > > #

[Python-ideas] Re: Keyword arguments self-assignment

On Tue, Apr 21, 2020 at 7:01 PM M.-A. Lemburg wrote: > Instead of keeping values in local variables, you store > them in the namespace object and because this knows about > its attributes you can do a lot more in terms of introspection > than what is possible when just relying on local variables

[Python-ideas] Re: Keyword arguments self-assignment

On Tue, Apr 21, 2020 at 11:01 AM M.-A. Lemburg wrote: > On 21.04.2020 10:07, Alex Hall wrote: > > > > > > On Tue, Apr 21, 2020 at 9:45 AM M.-A. Lemburg > > wrote: > > > > In the use case discussed here, that namespace would be > > locals(), so you could just as

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

21.04.20 11:15, Antoine Pitrou пише: Of course, the fact that zip() is the shorter form that everyone is used to means that, even if a `strict` argument is added, few people will bother adding it. The possible solution is to introduce zip_shortest() with the current behavior of zip(), make

[Python-ideas] Re: Keyword arguments self-assignment

On 21.04.2020 10:07, Alex Hall wrote: > > > On Tue, Apr 21, 2020 at 9:45 AM M.-A. Lemburg > wrote: > > In the use case discussed here, that namespace would be > locals(), so you could just as well write render_template(**locals()), > > > Doing that gets in the

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

21.04.20 11:49, Ram Rachum пише: There is more interesting example:      x = iter(range(5))      y = [0]      z = iter(range(5))      try:          zipped = list(zip(x, y, z, strict=True))      except ValueError: # assuming that’s the exception you want?  

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Sun, Apr 19, 2020 at 10:50 PM Alex Hall wrote: > On Sun, Apr 19, 2020 at 5:59 PM David Mertz wrote: > >> > I think you've missed on alternative. Well, it's a variation on "status >> quo": Use a silly magic helper function like my Q() or Alex' dict_of() in >> his sorcery library. >> >> >

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

On Tue, Apr 21, 2020 at 11:36 AM Serhiy Storchaka wrote: > 20.04.20 23:33, Andrew Barnert via Python-ideas пише: > > Should this print 1 or 2 or raise StopIteration or be a don’t-care? > > > > Should it matter if you zip(y, x, strict=True) instead? > > It should print 2 in both cases. The only

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

20.04.20 23:33, Andrew Barnert via Python-ideas пише: Should this print 1 or 2 or raise StopIteration or be a don’t-care? Should it matter if you zip(y, x, strict=True) instead? It should print 2 in both cases. The only way to determine whether the iterator ends is to try to get its next

[Python-ideas] Re: Keyword arguments self-assignment

On 21.04.2020 04:25, Andrew Barnert via Python-ideas wrote: > On Apr 20, 2020, at 16:24, M.-A. Lemburg wrote: >> >> On 20.04.2020 19:43, Andrew Barnert via Python-ideas wrote: On Apr 20, 2020, at 01:06, M.-A. Lemburg wrote: The current version already strikes me as way too

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

On Mon, 20 Apr 2020 12:39:05 -0700 Andrew Barnert via Python-ideas wrote: > On Apr 20, 2020, at 11:25, Brandt Bucher wrote: > > > > I disagree. In my own personal experience, ~80% of the time when I use > > `zip` there is an assumption that all of the iterables are the same length. > > > >

[Python-ideas] Re: Keyword arguments self-assignment

On Tue, Apr 21, 2020 at 9:45 AM M.-A. Lemburg wrote: > In the use case discussed here, that namespace would be > locals(), so you could just as well write render_template(**locals()), > Doing that gets in the way of tools. At the very least it makes it impossible to highlight accidentally

[Python-ideas] Re: Keyword arguments self-assignment

On Tue, Apr 21, 2020 at 5:41 PM M.-A. Lemburg wrote: > > On 21.04.2020 06:56, Chris Angelico wrote: > > On Tue, Apr 21, 2020 at 9:27 AM M.-A. Lemburg wrote: > >> But arguing that f(a=, b=, c=, d=) is any better than > >> f(a=a, b=b, c=c, d=d) does not really solve anything. > >> > >> The problem

[Python-ideas] Re: Keyword arguments self-assignment

On 21.04.2020 06:56, Chris Angelico wrote: > On Tue, Apr 21, 2020 at 9:27 AM M.-A. Lemburg wrote: >> But arguing that f(a=, b=, c=, d=) is any better than >> f(a=a, b=b, c=c, d=d) does not really solve anything. >> >> The problem is with the code design, not with the syntax. >> >> You'd be better