On Sat, May 2, 2020 at 4:38 AM Soni L. <fakedme+py@gmail.com> wrote:

On 2020-05-01 3:10 p.m., 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!

What about using an optional kwarg for a handler for mismatched lengths? I made a post about it on the other thread and it's not addressed in the PEP. It'd make zip capable of doing zip_shortest, zip_equal (aka zip(strict=True)) and zip_longest, it's not stringly-typed, and it's user-extensible. Something along the lines of zip(foo, bar, baz, and_then=lambda consumed_items, iters: ...).

YAGNI. ChrisA

On Sat, May 2, 2020 at 5:21 AM Soni L. <fakedme+py@gmail.com> wrote:

On 2020-05-01 3:41 p.m., Chris Angelico wrote:

...

On Sat, May 2, 2020 at 4:38 AM Soni L. <fakedme+py@gmail.com> wrote:

...

On 2020-05-01 3:10 p.m., 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!

What about using an optional kwarg for a handler for mismatched lengths? I made a post about it on the other thread and it's not addressed in the PEP. It'd make zip capable of doing zip_shortest, zip_equal (aka zip(strict=True)) and zip_longest, it's not stringly-typed, and it's user-extensible. Something along the lines of zip(foo, bar, baz, and_then=lambda consumed_items, iters: ...).

YAGNI.

examples:

# iterates in chunks, e.g. a very large file that wouldn't fit all in RAM zip(*[iter(x)]*32, and_then=lambda res, _: (yield res))

I'm honestly not sure how useful this really is in practice. Iterating over a file is already going to be chunked. What do you gain by wrapping it up in an opaque zip call?

# strict zip sentinel = object() def zip_eq(res, iters): if res or any(next(x, sentinel) is not sentinel for x in iters): raise ValueError zip(a, b, c, and_then=zip_eq) # this would ideally be zip.strict e.g. zip(a, b, c, and_then=zip.strict), but w/e.

So.... a messier and noisier spelling of what's already in this proposal...

# normal (shortest) zip but using an explicit function def no_op(*args, **kwargs): pass zip(a, b, c, and_then=no_op)

... and a messier and noisier spelling of what we already have. I say again, YAGNI. Give an actual use-case for the excessive generality of your proposal - namely, the ability to provide a custom function. And show that it's better with zip than just with a custom generator function. ChrisA

but the main benefit is, again, being able to get the iterated values which were silently swallowed by zip when the iteration stopped.

I don't think the call back idea is terrible, however, it doesn't really seem to have a usecase that isn't covered by zip_longest with a sentinel. Now as discussed in the main thread zip strict could also be handled by zip_longest with a sentinel. However, zip strict is an incredibly common usecase. There is no evidence that recovering the consumed elements is.

also: I don't like booleans. they're not extensible, unless you consider None. you either get it right the first time, add a new boolean argument later, or use enum.Flag from the beginning. this callback-based API sidesteps all these issues

While in theory I very much support the use of enums for flags, they have serious performance problems which makes their use inadvisable in the standard lib let alone a builtin. https://bugs.python.org/issue39102 https://bugs.python.org/issue38659 On Fri, May 1, 2020 at 1:20 PM Soni L. <fakedme+py@gmail.com> wrote:

...

On Sat, May 2, 2020 at 5:21 AM Soni L. <fakedme+py@gmail.com> wrote:

...

On 2020-05-01 3:41 p.m., Chris Angelico wrote:

...

On Sat, May 2, 2020 at 4:38 AM Soni L. <fakedme+py@gmail.com> wrote:

...

On 2020-05-01 3:10 p.m., 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!

...

...

...

What about using an optional kwarg for a handler for mismatched

lengths?

...

I made a post about it on the other thread and it's not addressed in the PEP. It'd make zip capable of doing zip_shortest, zip_equal (aka zip(strict=True)) and zip_longest, it's not stringly-typed, and it's user-extensible. Something along the lines of zip(foo, bar, baz, and_then=lambda consumed_items, iters: ...).

YAGNI.

examples:

# iterates in chunks, e.g. a very large file that wouldn't fit all in RAM zip(*[iter(x)]*32, and_then=lambda res, _: (yield res))

I'm honestly not sure how useful this really is in practice. Iterating over a file is already going to be chunked. What do you gain by wrapping it up in an opaque zip call?

...

# strict zip sentinel = object() def zip_eq(res, iters): if res or any(next(x, sentinel) is not sentinel for x in iters): raise ValueError zip(a, b, c, and_then=zip_eq) # this would ideally be zip.strict e.g. zip(a, b, c, and_then=zip.strict), but w/e.

So.... a messier and noisier spelling of what's already in this

On 2020-05-01 4:43 p.m., Chris Angelico wrote: proposal...

...

...

# normal (shortest) zip but using an explicit function def no_op(*args, **kwargs): pass zip(a, b, c, and_then=no_op)

... and a messier and noisier spelling of what we already have.

I say again, YAGNI. Give an actual use-case for the excessive generality of your proposal - namely, the ability to provide a custom function. And show that it's better with zip than just with a custom generator function.

we can finally push for the no_op function, for starters. but the main benefit is, again, being able to get the iterated values which were silently swallowed by zip when the iteration stopped.

also: I don't like booleans. they're not extensible, unless you consider None. you either get it right the first time, add a new boolean argument later, or use enum.Flag from the beginning. this callback-based API sidesteps all these issues.

and just in case maybe zip(strict=True) should be zip(errors=True) and we can later change it to zip(errors="replace", value=Foo) to get zip_longest >.< (no really bools = bad please don't use them in new APIs)

...

ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at

https://mail.python.org/archives/list/python-ideas@python.org/message/UAQGBS...

...

Code of Conduct: http://python.org/psf/codeofconduct/

---

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

On Fri, May 1, 2020 at 5:55 PM Andrew Barnert via Python-ideas < python-ideas@python.org> wrote:

On May 1, 2020, at 11:19, Brandt Bucher <brandtbucher@gmail.com> wrote:

...

I have pushed a first draft of PEP 618:

https://www.python.org/dev/peps/pep-0618

The document says “… with nobody challenging the use of the word ‘strict’”, but people did challenge it, and even more people just called it “equal” instead of “strict” when arguing for it or +’ing it (which implies a preference even if there’s no argument there), and the only known prior art on this is more-itertools, which has a zip_equal function, not a zip_strict function.

I completely agree with this. I didn't bother replying to the original thread as other people had already mentioned my favourite idea which was to use something like mode = "equal" | "shortest" | "longest" with "shortest" as the default (avoiding causing any breakage with the existing function). André Roberge

I think it misrepresents the arguments for a separate function and undersells the advantages—it basically just addresses the objections that are easiest to reject. I don’t want to rehash all of my arguments and those of a dozen other people, since they’re already in the thread, but let me just give one: A separate function can be used in third-party libraries immediately, as long as there’s an available backport (whether that’s more-iterools, or a trivial zip39 or whatever) that they can require; a flag can’t be used in libraries until they’re able to require Python 3.9 (unless they want to use a backport that monkey patches or shadows the builtin, but I doubt you’d suggest that, since you called it an antipattern elsewhere in the PEP).

It implies that infinite iterators are the only legitimate place where you’d ever want the existing shortest behavior.

Also, I don’t think anyone on the thread suggested the alternative of changing the behavior of zip _today_. Serhiy only suggested that we should leave the door open to doing so in the future, by having an enum-valued flag instead of a bool, or zip_shortest alongside zip_equal and zip_longest, or whatever. That allows people to explicitly say they want shortest when they want it, now—which might be beneficial even on its own terms. And if people end up usually using strict, and usually being explicit when they want shortest, then at that point it might be worth changing the default (or just not having one). So the argument against the alternative doesn’t really cover the actual thing suggested, but a different thing nobody wanted.

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

On Fri, May 01, 2020 at 11:30:17PM +0200, Alex Hall wrote:

Specifically the PEP says:

...

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.

I think the PEP is saying it'd be an antipattern to shadow zip with a version that is always strict. If you want both strict and non-strict in the same file, you're in trouble.

Then don't do it! If you want both, then it is trivially easy to use both: from itertools import zip_equal zip(zip_equal(a, b), c)

But replacing zip with a zip that has an optional strict flag should be harmless.

[Aside: I still disagree *strongly* with the use of a "strict" flag here.] Indeed, that's a perfectly safe and fine use of shadowing. Python is designed to allow shadowing. Calling it an "anti-pattern" is just wrong. Yes, shadowing can be abused, or done by accident, but intentional shadowing is a useful software design pattern. For instance: if not settings['print_diagnostics']: print = lambda *args, **kw: None def main(): print('diagnostics go here') ... -- Steven

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 to need to flesh this idea out, and write a better explanation of its benefits. Maybe one of the folks that are advocating for that could write it. At the very least, specifically mentioning the alternative is to add "zip_equal" or "zip_strict" to itertools, alongside zip_longest(). Personally, I still come down on the add a flag to zip() as the best option, but don't think the alternative is easily dismissed. I would note that while this is written, please be clear that it matters that zip() is a bulletin, and zip_liongest() is in itertools, so there is no way to have the three versions alongside each other for easy discoverability. That is, this would be analogous to having atan() as a builtin, and atan2() in the math module, rather than analogous to having to go to the math module to find all the trig functions, or having related methods on the string object. 3) A number of us prefer to add a string flag or enum: mode= "shortest" | "equal" | "longest" rather than a boolean flag. Yes, this would be redundant with zip_longest(), but it would better address the issue of having two modes in the builtin, and having to go to another module for the third mode. Whether you want to advocate for that or not, it should be mentioned. NOTE: for my part, I much prefer a string flag over an enum 4) " hand-writing a robust solution that gets this right isn't trivial" -- Alex Hall pointed to some great examples of this that you may want to cite. Thanks! -CHB On Sat, May 2, 2020 at 7:02 AM Jonathan Fine <jfine2358@gmail.com> wrote:

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 valuable contributions.

Here's a use-case for having a callback. It's the real-world code example given in the draft PEP 618: >>> from ast import Constant, Dict, literal_eval >>> nasty_dict = Dict(keys=[Constant("XXX")], values=[]) >>> literal_eval(nasty_dict) # Like eval('{"XXX": }') {}

If literal_eval resulted in a call to zip(..., strict=True) the outcome would be something like: Traceback (most recent call last): ValueError: zip() argument 2 is too short

It's good, very good, in this situation to get an error message rather than a wrong answer. That would make debugging really hard. And providing a better error message would be even more helpful. How about something like Traceback (most recent call last): AstValueError: Dict called with more keys than values

There. Isn't that even better for the programmer who's got to understand where the error came from. Clearly this outcome could be achieved using a custom callback. Here's the pure-Python implementation in the PEP if items: i = len(items) + 1 raise ValueError(f"zip() argument {i} is too short") sentinel = object() for i, iterator in enumerate(iterators[1:], 2): if next(iterator, sentinel) is not sentinel: raise ValueError(f"zip() argument {i} is too long")

Use this as the template for the custom callback. A simple change to the code allows the result to be an AstValueError, or whatever is considered appropriate.

In the PEP, the only exceptions raised directly by zip are StopIteration and ValueError. I've a question / problem. Wrap zip(..., strict=True) in such a way that the ast example above (taken from the PEP) results in an AstValueError. (Hint: There are traps for the unwary.)

By the way, as the PEP points out, the ValueError can be written as {'AAA':}. So maybe AstSyntaxError would be better.

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

-- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

On Sun, May 3, 2020 at 3:39 PM Dominik Vilsmeier <dominik.vilsmeier@gmx.de> 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=True) # ?

Admittedly the word "strict" in the context of `map` would be rather confusing.

This a really good argument for "equal" rather than "strict". -CHB

...

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

On 01.05.20 20:10, Brandt Bucher wrote: that hasn't yet been addressed in the PEP!

...

Brandt _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at

https://mail.python.org/archives/list/python-ideas@python.org/message/ZBB5L2...

...

Code of Conduct: http://python.org/psf/codeofconduct/

---

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

-- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

On Sun, May 3, 2020 at 6:17 PM Steven D'Aprano <steve@pearwood.info> 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 why this would be confusing for `map` but not `zip`. And "equal" might suggest that x and y need to be equal.

of course it would be confusing for zip. I and others have been advocating for "equal" over "strict" for a whiie. this is yet another argument. Since I never liked "strict", I'm not sure I can argue why it might be more confusing or map than zip :-) Perhaps "truncate" or even "trunc" is a better keyword than either

strict or equal. Not that I'm arguing for a keyword here.

But it wouldn't be truncating anything. If we want to be wordy, equal_length would do it -- but I wouldn't want to be that wordy. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

"strict" doesn't say what it's being strict about. That information has to be inferred by the reader. As a keyword argument I'd expect it to relate to the function's main purpose, so for `zip` I can understand how this refers to the arguments (since their items end up in the resulting tuples). However the main purpose of `map` is to produce new values, that depend on the provided function, so here the focus shifts from the input to the result. Hence I'd expect that `strict=True` refers to the produced values somehow (perhaps asserting that no value is produced twice). So if `zip` gets `strict=True` then I think it's clearer if `map` got `zip_strict=True`, as it's being explicit about its relation to the arguments. On 04.05.20 06:57, Guido van Rossum wrote:

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 the elements might be involved somehow.

On Sun, May 3, 2020 at 9:42 PM Christopher Barker <pythonchb@gmail.com <mailto:pythonchb@gmail.com>> wrote:

On Sun, May 3, 2020 at 6:17 PM Steven D'Aprano <steve@pearwood.info <mailto:steve@pearwood.info>> 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 why this would be confusing for `map` but not `zip`. And "equal" might suggest that x and y need to be equal.

of course it would be confusing for zip. I and others have been advocating for "equal" over "strict" for a whiie. this is yet another argument. Since I never liked "strict", I'm not sure I can argue why it might be more confusing or map than zip :-)

Perhaps "truncate" or even "trunc" is a better keyword than either strict or equal. Not that I'm arguing for a keyword here.

But it wouldn't be truncating anything. If we want to be wordy, equal_length would do it -- but I wouldn't want to be that wordy.

-CHB

-- Christopher Barker, PhD

Python Language Consulting   - Teaching   - Scientific Software Development   - Desktop GUI and Web Development   - wxPython, numpy, scipy, Cython _______________________________________________ Python-ideas mailing list -- python-ideas@python.org <mailto:python-ideas@python.org> To unsubscribe send an email to python-ideas-leave@python.org <mailto:python-ideas-leave@python.org> https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DK3PG4... Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido van Rossum (python.org/~guido <http://python.org/~guido>) /Pronouns: he/him //(why is my pronoun here?)/ <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>

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

How about "balanced" or "exact" as possible names. The main thing that I think is vital is for the docstring(s) to mention that they all exist - the current zip (in 3.8) doesn't mention zip_longest so if you don't already know about it. Or even how about calling any flag/parameter "tail", "spare" or "pad" - (the last would be my preferred) if it is an exception type, including StopIteration, when any of the input iterators runs out then that exception is raised, (StopIteration would give the zip_shortest behaviour), or a value that is used to extend the exhausted iterator(s). I think that this would also work well for map as well. Steve Barnes (sorry for top posting - Outlook) -----Original Message----- From: MRAB <python@mrabarnett.plus.com> Sent: 04 May 2020 17:55 To: python-ideas@python.org Subject: [Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip On 2020-05-04 13:17, Dominik Vilsmeier wrote:

"strict" doesn't say what it's being strict about. That information has to be inferred by the reader. [snip]

And "equal" doesn't say what it's equal. What we need is a word that means "same length", much as "shorter" and "longer" are about length. There's "coextensive", but that'll probably get a -1. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/K3OGDV... Code of Conduct: http://python.org/psf/codeofconduct/

Dominik Vilsmeier writes:

Or simply "samelength".

If we're going to do this to the builtin (I'm still -1 on changing the builtin FWIW), I'm persuaded by Chris Barkley's (somewhat different) argument that we may as well combine all the functionality in the builtin. How about zip(*iterables, length="shortest") # "shortest" is default zip(*iterables, length="longest", fill=None) # None is default zip(*iterables, length="checksame") # or just "same" or "checkequal" etc As the odd suggested value "checksame" shows, I see these semantics as not exactly congruent. But I think the argument name "length" addresses the concern about the ambiguity of various argument names.

On Wed, May 6, 2020 at 10:31 AM Alex Hall <alex.mojaki@gmail.com> wrote: zip.shortest(...) # same as zip(...) zip.longest(...) zip.checksame(...) I presume that zip() would keep its current behavior, yes? I kind of like this -- is there any precedent for it in the standard library? The PEP seems to reject this saying: The actual zip type is an undocumented implementation detail. Adding

additional methods or constructors is really a much larger change that is not necessary to achieve the stated goal.

well, yes and no -- the first part indicates that we could totally change the type of the zip, as long as it's a collable that returns an iterator. Whether adding additional methods is too large a change -- that's totally a matter of opinion.

Having these alternative 'methods' would be similar to having different functions in itertools, indeed -- same idea, different namepace.

-CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

On Thu, May 7, 2020 at 10:27 AM David Mertz <mertz@gnosis.cx> wrote:

The only precedent that jumps out for me is itertools.chain() and itertools.chain.from_iterable(). It's quite likely that something I don't use much has used the same pattern though.

(Please don't top-post - you're making it hard to give proper context. Precedent for what?) That's an example of a very common pattern of alternate constructors. So if you want to parallel that with zip, the most logical way would be something like zip.from_same_length_iterables() or some abbreviation. And then zip_longest could become zip.from_iterables_and_fill(). I don't see that this would be an advantage, but hey, it's plausible :) ChrisA

On Thu, May 7, 2020 at 11:16 AM David Mertz <mertz@gnosis.cx> wrote:

On Wed, May 6, 2020 at 8:37 PM Chris Angelico <rosuav@gmail.com> wrote:

...

...

The only precedent that jumps out for me is itertools.chain() and itertools.chain.from_iterable(). It's quite likely that something I don't use much has used the same pattern though.

That's an example of a very common pattern of alternate constructors.

The other Chris' comment was:

...

zip.shortest(...) # same as zip(...) / zip.longest(...) / zip.checksame(...) I kind of like this -- is there any precedent for it in the standard library?

If it's a very common pattern, do you know of any in the standard library beyond the one I mentioned? Not about bikeshedding the spelling of the different constructors, but just:

1. A callable; 2. That has one or more functions attached to perform some variation on what that callable itself does.

The first one that comes to mind is the datetime types, which have from* methods that construct them from timestamps, strings, etc. A quick search of the cpython/Lib directory shows Decimal.from_float, dict.fromkeys, socket.fromfd, and a bunch of others, all of the basic form "construct one of these things in a slightly different way". On Thu, May 7, 2020 at 11:19 AM Eric V. Smith <eric@trueblade.com> wrote:

I think David is right: itertools.chain.from_iterable() is the only place I know of with an attribute on a function that's another function. Alternate constructors are generally classmethods. Not that the distinction is terribly important, but it is a distinction, and it's documented differently.

What do you mean? Are you saying that itertools.chain is a function but datetime.datetime is a class, and that this is fundamentally different? Because Python disagrees:

...

...

import itertools, datetime type(itertools.chain), type(datetime.datetime) (<class 'type'>, <class 'type'>)

itertools.chain.from_iterable is a classmethod (albeit implemented in C, in current CPython). ChrisA

On Wed, May 6, 2020 at 10:34 PM David Mertz <mertz@gnosis.cx> wrote:

...

...

zip.shortest(...) # same as zip(...) / zip.longest(...) / zip.checksame(...)

This is a very good example. chain.from_iterator() feels a little weak to me since there's just the one alternate constructor, whereas zip would hypothetically have several.

But I actual do use both 'datetime(...)' and 'datetime.fromfoo(...)' in practice. I had forgotten those.

I don't prefer this API, but I don't hate it given the examples.

zip.shortest(), zip.same or .equal or .checksame(), zip.longest().... I really like how smoothly those read. +1 on this from me. --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler

...

The only precedent that jumps out for me is itertools.chain() and itertools.chain.from_iterable(). It's quite likely that something I don't use much has used the same pattern though.

I think David is right: itertools.chain.from_iterable() is the only

place I know of with an attribute on a function that's another function. Alternate constructors are generally classmethods. Not that the distinction is terribly important, but it is a distinction, and it's documented differently.

I don't think being a function versus a classmethod is important here. Just that the underlying name is *callable*. If the implementation was like this dumb example, it wouldn't matter that it was a class instance (e.g. for a hypothetical `greet` builtin)

...

...

class Greeting: ... def __call__(self, name): ... print("Hello", name) ... def twice(self, name): ... print(f"Hi {name}, howdy there!") ... greet = Greeting() greet('Eric') Hello Eric greet.twice('Eric') Hi Eric, howdy there!

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

On Thu, May 7, 2020 at 11:56 AM Eric Fahlgren <ericfahlgren@gmail.com> wrote:

On Wed, May 6, 2020 at 6:27 PM David Mertz <mertz@gnosis.cx> wrote:

...

I don't think being a function versus a classmethod is important here. Just that the underlying name is *callable*.

But wait a minute, zip isn't just a "callable", it's a class, and adding more methods to it seems perfectly natural, just like lots of other built-in classes.

...

...

...

zip <class 'zip'> int <class 'int'> int.to_bytes(97, 4, 'little') b'a\x00\x00\x00'

That one is more normally written as (97).to_bytes(4, 'little') but a better example would be the converse int.from_bytes(b'a\0\0\0', 'little') == 97, as that's a class method. ChrisA

But wait a minute, zip isn't just a "callable", it's a class, and adding more methods to it seems perfectly natural, just like lots of other built-in classes.

Zip is a class in CPython 3.8. it may or may not be in other implementations or versions. The API users are currently promised says nothing about it needing to be implemented as a class.

and it was a function in 2.7. But though Python blurs the lines between various callables and functions, there is a general "sense" of how they are used. And for the most part, zip is not used like a class. WE "use" classes, usually, by creating instances, and then calling various methods on them, etc. a zip instance on the other hand, returns an iterable, that does not provide any other methods or uses. I have to say, I have not idea why zip is a class rather than a function that returns a zip_iterator instance, but it is certainly an implementation detail. So while yes, alternate constructors are a common pattern, I don't think they are a common pattern for classes like zip. That being said, I still like it. -CHB

Moreover, even if Python 3.9 decides to make zip() a function instead, that wouldn't prevent the alternate constructors being implemented. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RWE6ZE... Code of Conduct: http://python.org/psf/codeofconduct/

-- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

Christopher Barker writes:

But though Python blurs the lines between various callables and functions, there is a general "sense" of how they are used. And for the most part, zip is not used like a class. WE "use" classes, usually, by creating instances, and then calling various methods on them, etc.

I think this is a distinction without a difference at the margin. In the end, all callables return objects, aka instances. The class *statement* is special, of course (although to me it's remarkable how little is special about it). But then consider factory functions. From the outside, what's special about them is that conventionally they always return objects from a specific class, and that's why they get a special name. These distinctions are very useful to humans thinking about a program (well, they are to me!), but they're fuzzy. So of course zip can be said to be used like a class. Its instances are constructed by calling it, the most common (only in practice?) method call is .__iter__, it's invariably called implicitly in a for statement, and usually the instance is ephemeral (ie, discarded when the for statement is exited). But it needn't be. Like any iterator, if it's not exhausted in one iteration context, you can continue it later. Or explicitly call next on it.

a zip instance on the other hand, returns an iterable, that does not provide any other methods or uses.

A zip instance *is* an iterator (though that's not in its name), and it has quite a few methods ;-) as you can check with dir(). It's just that the three most interesting ones (__init__, __iter__, and __next__) are invariably invoked implicitly.

So while yes, alternate constructors are a common pattern, I don't think they are a common pattern for classes like zip.

That's a matter of programming style, I think. There's no real difference between zip(a, b, length='checksame') and zip.checksame(a, b) They just initialize an internal attribute differently, which takes one of a very few values. I think (after the initial shock ;-) I like the latter *better*, because the semantics of checksame and longest are significantly (to me, anyway) different. checksame is a constraint on correct behavior, and explicitly elicits an Exception on invalid input. longest is a variant specification of behavior on a certain class of valid input. I'm happier with those being different *functions* rather than values of an argument. YMMV, of course. There's another possibility, as well: zip(a,b).set_check_same() but this is bad style IMO (it would have to return self or you couldn't "for pair in zip(a,b).set_check_same()", and I don't like methods that both mutate an object and return self, though some folks do). Steve

Dominik Vilsmeier writes:

Maybe people start writing code like this:

    if not zip.checksame(a, b):         raise ValueError()     for stuff in zip(a, b):

At some point you just have to hope that people read documentation. Maybe there's a better name; that one was originally chosen for a value of the length argument, and got moved to a class method on zip "as is". I guess you could go for something like "zip.while_asserting_same_length".

On Thu, May 07, 2020 at 11:12:28PM +0900, Stephen J. Turnbull wrote: [...]

So of course zip can be said to be used like a class. Its instances are constructed by calling it, the most common (only in practice?) method call is .__iter__, it's invariably called implicitly in a for statement, and usually the instance is ephemeral (ie, discarded when the for statement is exited). But it needn't be. Like any iterator, if it's not exhausted in one iteration context, you can continue it later. Or explicitly call next on it.

Agreed. In CPython 3.x, zip is a class. In 2.x it was a function returning a list. I don't know why it's a class now -- possibly something to do with the C implementation? -- but that's not part of the public API, and I would not expect that to be a language guarantee. The API is only that it returns an iterator, it doesn't have to be any specific class. If zip were implemented in pure Python, it would probably be a generator, something like this: def zip(a, b): while True: yield(next(a), next(b)) only better :-) [...]

...

So while yes, alternate constructors are a common pattern, I don't think they are a common pattern for classes like zip.

That's a matter of programming style, I think. There's no real difference between

zip(a, b, length='checksame')

and

zip.checksame(a, b)

They just initialize an internal attribute differently, which may as well be an Enum or even a few named class constants.

I agree that it's a matter of programming style, but I disagree with your reason. It isn't necessary for the methods to return instances of the same class, they could also return different classes. An old example of this from Python 2 was int/long unification: py> type(int(1e1)) <type 'int'> py> type(int(1e100)) <type 'long'> A current example of this is the open() built-in, which returns a different class depending on the arguments given. For example: py> open('/tmp/a', 'wb') <_io.BufferedWriter name='/tmp/a'> py> open('/tmp/a', 'w') <_io.TextIOWrapper name='/tmp/a' mode='w' encoding='UTF-8'> So we might have: zip() --> return a zip instance zip.checksame() --> return a zip_strict instance for example. The specific type of iterator is an implementation detail.

I think (after the initial shock ;-) I like the latter *better*, because the semantics of checksame and longest are significantly (to me, anyway) different. checksame is a constraint on correct behavior, and explicitly elicits an Exception on invalid input. longest is a variant specification of behavior on a certain class of valid input. I'm happier with those being different *functions* rather than values of an argument. YMMV, of course.

If we reach consensus that this functionality is worth having and worth being in the builtins, my preferences would go (best to worst): (1) Namespaces are one honking great idea -- let's do more of those! zip is a namespace, let's use that fact: zip(*args) # for backwards compatibility zip.strict(*args) This gives us the best flexibility going into the future. We can add new versions of zip without overloading the builtins itself: there is only one top level name, and the docstring can point the reader at dir(zip) to see more. At some point, we might choose to move zip_longest into zip as well, leaving the itertools version for backwards compatibility. Maybe some day Soni will even get his desired version of zip that exposes any partial results left over after an iterator is exhausted. This idiom is particularly convenient since zip is a class and can easily be given additional methods, so they would show up in help(zip) without any extra work. (2) Separate top-level functions: zip, zip_strict (3) A mode parameter: zip(*args, mode='short') # default zip(*args, mode='strict') and then a long, long, long way down my list of preferred APIs: (4) A bool flag: zip(*args, strict=False) # default zip(*args, strict=True) which is the least flexible, since it locks us in to only two such zip versions without going into API contortions. -- Steven

On May 9, 2020, at 03:46, Chris Angelico <rosuav@gmail.com> wrote:

But ultimately, a generator function is very similar to a class with a __next__ method. When you call it, you get back a state object that you can ping for the next value. That's really all that matters.

Well, it’s very similar to a class with __next__, send, throw, and close methods. But that doesn’t really change your point. For a different angle on this: What If Python 3.10 changed things so that every generator function actually did define a new class (maybe even accessible as a member of the function)? What would break? You could make inspect.isgenerator() continue to work, and provide the same internal attributes documented in the inspect module. So only code that depends on type(gen()) is types.GeneratorType would break (and there probably is very little of that—not even throwaway REPL code). Also: a generator isn’t actually a way of defining a class, but it’s a way of defining a factory for objects that meet a certain API, and Python goes out of its way to hide that distinction wherever possible (not just for generators, but in general). The only meaningful thing that’s different between a generator function and a generator class is that the author of the function doesn’t directly write the __next__ (and send, close, etc.) code, but instead writes code that defines their behavior implicitly. And that’s obviously just an implementation detail, and it isn’t that much different from the fact that the author of a @dataclsss doesn’t directly write the __init__, __repr__, etc. So you’re right, from outside, it really doesn’t matter.

I think the C implementations tend to be classes but the Python ones tend to be generators - possibly because a generator function is way easier to write in Python, but maybe the advantage isn't as strong in C.

It’s not just not as strong, it runs in the opposite direction. In fact, it’s impossible to write generator functions in C. There’s no way to yield control in a C function. (Even if you build a coro library around setjmp, or use C++20 coros, it wouldn’t help you yield back into CPython’s ceval loop.) A generator object is basically just a wrapper around an interpreter frame and its bytecode; there’s no way to exploit that from C. There are a few shortcuts to writing an iterator (e.g., when you have a raw array, implement the old-style sequence protocol, want to delegate to a member, or can steal another type’s implementation as frozenset does with set), but a generator function isn’t one of them. (If you’re curious how Cython compiles generators, it’s worth looking at what it produces—but doing the same thing in raw C would not be a shortcut to writing a generator class.)

Sorry for off topic. Isn't this chain.from_iterable just a historical legacy... now we have PEP 448 and I see no differences* between chain(*iterable) vs chain.from_iterable(iterable). Are there? * chain.from_iterable is a little bit faster for small iterables, but if at that time we had PEP 448, would this small speed benefits be enough to make additional method to chain. I think no. -gdg On Thu, May 7, 2020 at 3:24 AM David Mertz <mertz@gnosis.cx> wrote:

The only precedent that jumps out for me is itertools.chain() and itertools.chain.from_iterable(). It's quite likely that something I don't use much has used the same pattern though.

On Wed, May 6, 2020, 8:17 PM Christopher Barker <pythonchb@gmail.com> wrote:

...

On Wed, May 6, 2020 at 10:31 AM Alex Hall <alex.mojaki@gmail.com> wrote: zip.shortest(...) # same as zip(...) zip.longest(...) zip.checksame(...)

I presume that zip() would keep its current behavior, yes?

I kind of like this -- is there any precedent for it in the standard library?

The PEP seems to reject this saying:

The actual zip type is an undocumented implementation detail. Adding

...

additional methods or constructors is really a much larger change that is not necessary to achieve the stated goal.

well, yes and no -- the first part indicates that we could totally change the type of the zip, as long as it's a collable that returns an iterator.

Whether adding additional methods is too large a change -- that's totally a matter of opinion.

...

Having these alternative 'methods' would be similar to having different functions in itertools, indeed -- same idea, different namepace.

-CHB

-- Christopher Barker, PhD

Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5EC4BL... Code of Conduct: http://python.org/psf/codeofconduct/

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

On Thu, May 7, 2020 at 10:56 AM Alex Hall <alex.mojaki@gmail.com> wrote:

On Thu, May 7, 2020 at 9:48 AM Kirill Balunov <kirillbalunov@gmail.com> wrote:

...

Sorry for off topic. Isn't this chain.from_iterable just a historical legacy... now we have PEP 448 and I see no differences* between chain(*iterable) vs chain.from_iterable(iterable). Are there?

* chain.from_iterable is a little bit faster for small iterables, but if at that time we had PEP 448, would this small speed benefits be enough to make additional method to chain. I think no.

-gdg

`chain(*iterable)` converts iterable into a tuple, concretizing it in memory. chain.from_iterable(iterable) is lazy and goes through the elements one a time, meaning iterable can be infinite.

I don't think PEP 448 has any bearing on that.

Heh, surely, I misunderstood the point of PEP 448, and checked that it was also possible in Python 2. "meaning iterable can be infinite" - thank you, I missed this part, but to be honest I don’t remember when I do something useful with infinite iterables. -gdg

On May 4, 2020, at 10:44, Steve Barnes <GadgetSteve@live.co.uk> wrote:

And "equal" doesn't say what it's equal.

What we need is a word that means "same length", much as "shorter" and "longer" are about length.

There's "coextensive", but that'll probably get a -1.

If “equal” is bad, “coextensive” is much worse. “Equal” is arguably ambiguous between “same length” and “same values”, but “coextensive” usually means “same values”. “The County shall be coextensive with the City of San Francisco” doesn’t mean that it’s 49.81 square miles, it means it consists of the exact same 49.81 square miles as the city. “The golden age of Dutch culture was roughly coextensive with the Netherlands’ reign as a world power…” doesn’t mean it was roughly 67 years, it means it was roughly the same 67 years from 1585 to 1652.[1] “Consciousness and knowledge are coextensive” means that you know the things you’re conscious of. And in math[2], a popular example in undergrad textbooks[3] is that (Z/7Z, +) and (Z/7Z, *) are coextensive but still distinct groups. The most popular formulation of the axiom of reducibility in early predicative set theory was “to each propositional function there corresponds a coextensive predicative function”. Even in measure theory, it seems to always mean “same extension”, not “same extent”. So, this would be a great name for the function in the other thread about comparing lists and tuples as equal, but it’s not a great name here. Some dictionaries do give “commensurate” or similar as a secondary[4] meaning, but at best that would mean it’s still ambiguous. —- [1] And here I thought it was 1989 until whenever Guido left. [2] I didn’t even remember that it was used in math until I used the word in its normal English sense and one of the other Steves accused me or resorting to mathematical jargon—but after that, I did some searching, and I was wrong, and it actually is reasonably common. [3] Seriously, I found the exact same example in three apparently unrelated textbooks. Which is pretty odd. [4] Or even later, after giving the same spatial boundaries, then the same temporal boundaries, then the math/logic definition, but I’m lumping those all together as one sense because they’re coextensive if spacetime Is topological. :)

If you use the word 'even' and tell me it has to do with lengths (or any number) I'm going to think of multiples of 2, not equality. On Mon, May 4, 2020 at 3:52 PM <jdveiga@gmail.com> wrote:

Guido van Rossum wrote:

...

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 the elements might be involved somehow. On Sun, May 3, 2020 at 9:42 PM Christopher Barker pythonchb@gmail.com wrote:

...

On Sun, May 3, 2020 at 6:17 PM Steven D'Aprano steve@pearwood.info 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 why this would be confusing for map but not zip. And "equal" might suggest that x and y need to be equal. of course it would be confusing for zip. I and others have been advocating for "equal" over "strict" for a whiie. this is yet another argument. Since I never liked "strict", I'm not sure I can argue why it might be more confusing or map than zip :-) Perhaps "truncate" or even "trunc" is a better keyword than either strict or equal. Not that I'm arguing for a keyword here. But it wouldn't be truncating anything. If we want to be wordy, equal_length would do it -- but I wouldn't want to be that wordy. -CHB -- Christopher Barker, PhD Python Language Consulting

Teaching Scientific Software Development Desktop GUI and Web Development wxPython, numpy, scipy, Cython

Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at

https://mail.python.org/archives/list/python-ideas@python.org/message/DK3PG4. ..

...

Code of Conduct: http://python.org/psf/codeofconduct/ -- --Guido van Rossum (python.org/~guido) Pronouns: he/him **(why is my pronoun here?)

http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c. ..

What about `even` as "equal in number or amount"? _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GLAEXJ... Code of Conduct: http://python.org/psf/codeofconduct/

On Mon, May 04, 2020 at 02:18:15PM -0000, jdveiga@gmail.com wrote:

Ok,`even`is one of those scarce polysemic words in English ;-)

Meaning depends on context and message receiver's expectations, of course.

But... "add an even mixture of milk and cream" and "the curtain rod and the top of the window should be even" --examples taken from wordreference-- are quite similar to say "zip even iterators".

I don't know anyone who would say "an even mixture of milk and cream". Perhaps it is very old? As a native English speaker, I would say an equal amount. I don't know anyone who would use "even" in that way. There are occasions where "even" is used to mean equal, but they are relatively unusual and usually figurative, as in "now we're even" to imply that some figurative scales have been put into balance. We wouldn't say "you and I have been paid an even amount", that would imply multiples of two, not equality. The meaning of the second example is that the curtain rod and the top of the window should be parallel, not equal. [...]

Obviously, my prefer option is `force_equal_length` but... you know... verbose...

Also inaccurate, since the current behaviour of zip already is to *force* equal length by truncating (in the case of `zip`) or padding (`zip_longest`). The proposed function doesn't force equal length, it raises if that expectation isn't met. The current two versions of zip are tolerant of unequal iterators. The proposed version is not tolerant, it is strict, and requires the iterators to have the same length or it will raise. -- Steven

On Mon, May 4, 2020, 10:55 AM Ricky Teachey <ricky@teachey.org> wrote:

I'm wondering if a `mode` (or similar) keyword argument, with multiple possible options, should be included in the "rejected" section of the PEP.

zip(*args, mode="longest") <-- default zip(*args, mode="equal") <-- or "even"

Whoops apologies, I intended to say: zip(*args, mode="shortest") <-- default zip(*args, mode="equal") <-- or "even" And (correction in caps): An advantage of this way is if the option to zip in different ways proves

popular, you could later add zip LONGEST as an option, and maybe others I'm not smart enough to think of:

zip(*args, mode="longest")

The PEP should argue against doing this since `strict= True or False` forever limits you to only two modes of zipping.

On 04/05/2020 15:02, Alex Hall wrote: ...top-posted stuff in response to jdveiga@gmail.com, who had bottom posted. Guys, I know I'm not going to persuade either of you of the fundamental truth that posting interleaved replies is best, but if you're going to post at opposite ends of the chain of argument could you at least trim the middle out? -- Rhodri James *-* Kynesim Ltd

On Sun, May 03, 2020 at 09:41:00PM -0700, Christopher Barker wrote:

On Sun, May 3, 2020 at 6:17 PM Steven D'Aprano <steve@pearwood.info> 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 why this would be confusing for `map` but not `zip`. And "equal" might suggest that x and y need to be equal.

of course it would be confusing for zip.

Dominik seems to think that it is acceptable for zip but confusing for map, so I don't think that any confusion deserves to be described with "of course". At least, it's not obvious to me why it is confusing. We currently have a pair of zip functions that are tolerant of mismatched data: zip stops at the shortest input, and zip_longest pads the input. This proposal would be a strict version of zip. [...]

...

Perhaps "truncate" or even "trunc" is a better keyword than either strict or equal. Not that I'm arguing for a keyword here.

But it wouldn't be truncating anything.

`truncate=True` would be the current behaviour, which truncates at the shortest input: py> list(zip('a', range(100000))) [('a', 0)] -- Steven

I suspect it's because zip() is actually a class constructor, so argument zero is self... Paul On Wed, 20 May 2020 at 10:10, Neil Girdhar <mistersheik@gmail.com> wrote:

I'm just curious, but is it usual for errors to be one-based rather than zero-based? If I do zip(*iterables, strict=True), then "argument 1 is too long" refers to iterables[0]?

On Friday, May 1, 2020 at 2:20:12 PM UTC-4, 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 mailing list -- python...@python.org To unsubscribe send an email to python-id...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ZBB5L2... Code of Conduct: http://python.org/psf/codeofconduct/

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

On Wed, 20 May 2020 07:52:22 -0700 Guido van Rossum <guido@python.org> wrote:

No, it's because the message speaks English, not Python, and in English we count starting from one. Users would be very confused you counted from zero here,

Agreed. I would be confused myself. Regards Antoine.

On Wed, May 20, 2020 at 7:56 AM Guido van Rossum <guido@python.org> wrote:

No, it's because the message speaks English, not Python, and in English we count starting from one. Users would be very confused you counted from zero here,

And we can tell users that speak Geek more fluently that English that it's because "self" is zero :-) -CHB

On Wed, May 20, 2020 at 02:24 Paul Moore <p.f.moore@gmail.com> wrote:

...

I suspect it's because zip() is actually a class constructor, so argument zero is self... Paul

On Wed, 20 May 2020 at 10:10, Neil Girdhar <mistersheik@gmail.com> wrote:

...

I'm just curious, but is it usual for errors to be one-based rather

than zero-based? If I do zip(*iterables, strict=True), then "argument 1 is too long" refers to iterables[0]?

...

On Friday, May 1, 2020 at 2:20:12 PM UTC-4, 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 mailing list -- python...@python.org To unsubscribe send an email to python-id...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at

https://mail.python.org/archives/list/python-ideas@python.org/message/ZBB5L2...

...

Code of Conduct: http://python.org/psf/codeofconduct/

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

---

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

-- --Guido (mobile) _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IB7DGT... Code of Conduct: http://python.org/psf/codeofconduct/

-- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython