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

2020-05-15 Thread Paul Moore 
On Fri, 15 May 2020 at 07:10, Brandt Bucher  wrote:
>
> This whole sub-thread of discussion has left me very confused. Was anything 
> unclear in the PEP's phrasing here? If so, I'd like to improve it. The 
> original quote is: "The goal here is not just to provide a way to catch bugs, 
> but to also make it easy (even tempting) for a user to enable the check 
> whenever using `zip` at a call site with this property."

It's not unclear, I'm just not sure I agree with the goal, and I'm not
sure the proposal achieves that goal:

I note that the PEP makes no mention in the rationale of the goal to
make it "tempting" to use the flag. It's *only* mentioned as a reason
to reject the itertools option. If you want to use that argument, you
should explicitly state (and justify) the goal of making use of the
flag "tempting" in the rationale for the feature. If it's not part of
the rationale, your argument against an itertools function is weak
(arguably flawed).

My problems with the argument for rejection are:

1. Why do we want to "tempt" people to error when handling mismatched
lengths? Certainly letting people catch errors easily is worthwhile,
but rejecting arguments of different lengths may well *not* be an
error ("be lenient in what you accept" is a well-known principle, even
if not something that everyone agrees on in all cases).
2. I find "mode switch" arguments ugly, and I could even argue
difficult to maintain (I can't easily use grep to check whether I
missed any cases that I wanted to make strict). So I'm not tempted to
use one - rather the opposite, it puts me off. (Note that I'm *not*
arguing "mode switches are wrong", but rather that a mode switch makes
the functionality "more tempting").
3. I'm not even that sure it's easy to discover - a key factor in
making it something people will use when needed. People who know of
zip and zip_longest would naturally look for a zip_strict, not for a
mode argument. (Yes, this is not a strong point - *nobody* can really
tell what people in general will find "easy" - but it does at least
reflect *my* thought processes).

I do agree that a builtin is more "tempting" to use than a stdlib
function (it's not logical, but I can see that people think that way -
I do myself). What I don't agree with is that "tempting" is a goal
that we want, or that being a builtin is sufficiently important to
justify the downsides of a mode flag.

We may just have to agree to differ, and leave the final decision to
the SC. But let's at least be clear about the goals up front in the
rationale section.

Paul

PS Despite my reservations, this is a well-reasoned and well presented
PEP - you've put a lot of work into it, and it shows. Thanks!
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/IVLRMEXU454ZHT2SZJY374VSOZJHIGKE/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-15 Thread Stephen J. Turnbull 
Brandt Bucher writes:

 > Still agreed. But I think they would be *better* served by the
 > proposed keyword argument.
 > 
 > This whole sub-thread of discussion has left me very confused. Was
 > anything unclear in the PEP's phrasing here?

I thought it was quite clear.  Those of us who disagree simply
disagree.  We prefer to provide it as a separate function.  Just move
on, please; you're not going to convince us, and we're not going to
convince you.  Leave it to the PEP Delegate or Steering Council.

 > I wouldn't confuse "can" and "should" here.

You do exactly that in arguing for your preferred design, though.

We could implement the strictness test with an argument to the zip
builtin function, but I don't think we should.  I still can't think of
a concrete use case for it from my own experience.  Of course I
believe concrete use cases exist, but that introspection makes me
suspicious of the claim that this should be a builtin feature, with
what is to my taste an ugly API.

Again, I don't expect to convince you, and you shouldn't expect to
convince me, at least not without more concrete and persuasive use
cases than I've seen so far.

Steve
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/6NQZIDVMGPXA5QJWTKWJFZUUUAYQAOH4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-15 Thread Paul Ganssle 
I'm on the fence about using a separate function vs. a keyword argument
(I think there is merit to both), but one thing to note about the
separate function suggestion is that it makes it easier to write
backwards compatible code that doesn't rely on version checking. With
`itertools.zip_strict`, you can do some graceful degradation like so:

try:
    from itertools import zip_strict
except ImportError:
    zip_strict = zip

Or provide fallback easily:

try:
    from itertools import zip_strict
except ImportError:
    def zip_strict(*args):
    yield from zip(*args)
    for arg in args:
    if next(arg, None):
 raise ValueError("At least one input terminated early.")

There's an alternate pattern for the kwarg-only approach, which is to
just try it and see:

try:
    zip(strict=True)
    HAS_ZIP_STRICT = True
except TypeError:
    HAS_ZIP_STRICT = False

But I would say it's considerably less idiomatic.

Just food for thought here. In the long run this doesn't matter, because
eventually 3.9 will fall out of everyone's support matrices and these
workarounds will become obsolete anyway.

Best,
Paul

On 5/15/20 5:20 AM, Stephen J. Turnbull wrote:
> Brandt Bucher writes:
>
>  > Still agreed. But I think they would be *better* served by the
>  > proposed keyword argument.
>  > 
>  > This whole sub-thread of discussion has left me very confused. Was
>  > anything unclear in the PEP's phrasing here?
>
> I thought it was quite clear.  Those of us who disagree simply
> disagree.  We prefer to provide it as a separate function.  Just move
> on, please; you're not going to convince us, and we're not going to
> convince you.  Leave it to the PEP Delegate or Steering Council.
>
>  > I wouldn't confuse "can" and "should" here.
>
> You do exactly that in arguing for your preferred design, though.
>
> We could implement the strictness test with an argument to the zip
> builtin function, but I don't think we should.  I still can't think of
> a concrete use case for it from my own experience.  Of course I
> believe concrete use cases exist, but that introspection makes me
> suspicious of the claim that this should be a builtin feature, with
> what is to my taste an ugly API.
>
> Again, I don't expect to convince you, and you shouldn't expect to
> convince me, at least not without more concrete and persuasive use
> cases than I've seen so far.
>
> Steve
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/[email protected]/message/6NQZIDVMGPXA5QJWTKWJFZUUUAYQAOH4/
> Code of Conduct: http://python.org/psf/codeofconduct/



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/A4UGQRMKUZDBHEE4AFJ4PL6AUUTAPF7N/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-15 Thread Steven D'Aprano 
On Fri, May 15, 2020 at 08:17:12AM +0100, Paul Moore wrote:

> 1. Why do we want to "tempt" people to error when handling mismatched
> lengths? Certainly letting people catch errors easily is worthwhile,
> but rejecting arguments of different lengths may well *not* be an
> error ("be lenient in what you accept" is a well-known principle, even
> if not something that everyone agrees on in all cases).

I concur with Paul here.

There may be cases where mismatched lengths are an error, but there are 
also cases where they are not an error. It is patronising to be talking 
about tempting people into using the strict version of zip. People who 
need it will find it, whether it is builtin or not.


> 2. I find "mode switch" arguments ugly

I think we need to distinguish between *modes* and *flags*. This 
proposed functionality is a mode, not a flag.

Mode switches are extensible:

zip(*args, mode='strict')

can easily be extended in the future to support new modes, such as 
zip_longest. There are at least two other modes that have been mentioned 
briefly in the Python-Ideas thread:

1. a variety of zip that returns information in the StopIterator 
   exception identifying the argument that was empty and those that 
   weren't;

2. a variety of zip that simply skips the missing arguments:

zip_skip('abc', 'ef', 'g')
=> (a, e, g) (b, f), (c,)

I don't even understand the point of the first one, or how it would 
operate in practice, or why anyone would need it, but at least one 
person thinks it would be useful. Take that as you will.

But I have written my own version of the second one, and used it.

A mode parameter naturally implies that only one mode can apply at a 
time, and it naturally enforces that restriction without any additional 
programmer effort. If there are (let's say...) four different modes:

mode = shortest|longest|strict|skip

you can only supply one at a time.

Using *named modes* (whether as strings or enums) to switch modes is 
quite reasonable. It's not my preferred API for this, but I don't hate 
it.

But a *flag* parameter is difficult to extend without making both the 
API and the implementation complicated, since any extension will use 
multiple parameters:

zip(*args, strict=True, longest=False, skip=True)

and the caller can supply any combination, each of which has to be 
tested for, exceptions raised for the incompatible combinations. With 
three flags, there are eight such combinations, but only four valid 
ones. With four flags, there are 16 combinations and only five 
meaningful combinations.

Flags work tolerably well when the parameters are independent and 
orthogonal, so you can ask for any combination of flags.

But flags to switch modes are *not* independent and orthogonal. We can't 
combine them in arbitrary combinations. Using *boolean flags* to switch 
modes in this way makes for a poor API.

For the record, my preferred APIs for this are in order:

1. +1 itertools.zip_strict function
2. +1 zip.strict(*args)
3. +1 zip(*args, mode='strict')  # mode='shortest' by default
4. +0 zip(*args, strict=True)

and even that is being generous for option 4.

Note that options 1 and 2 have an important advantage over options 3 and 
4: the strict version of zip is a first-class callable object that can 
be directly passed around and used indirectly in a functional way.

E.g. for testing using unittest:

assertRaises(zip.strict, 'a', '', Exception)

Yes, assertRaises is also usable as a context manager, but this is just 
an illustration of the functional style.



-- 
Steven
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/ZSOFQ5MQLQOBYC4GWNFBBPYEWUNNCYKY/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-15 Thread Steven D'Aprano 
On Fri, May 15, 2020 at 09:56:03AM -0400, Paul Ganssle wrote:
> I'm on the fence about using a separate function vs. a keyword argument
> (I think there is merit to both), but one thing to note about the
> separate function suggestion is that it makes it easier to write
> backwards compatible code that doesn't rely on version checking. With
> `itertools.zip_strict`, you can do some graceful degradation like so:
> 
> try:
>     from itertools import zip_strict
> except ImportError:
>     zip_strict = zip

This is just a special case of a much broader case: a separate function, 
or method, is a first class object that can be passed around to other 
functions, used in lists, etc.

https://softwareengineering.stackexchange.com/questions/39742/when-is-a-feature-considered-a-first-class-citizen-in-a-programming-language-p

Using a mode switch or flag makes the zip strict a second class citizen.


-- 
Steven
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/KYEOWALI7EQEP6N2GZSSA5NUCW5KDQLW/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-15 Thread Chris Jerdonek 
Here’s another advantage of having a separate function that I didn’t see
acknowledged in the PEP:

If strict behavior is a better default for a zip-like function than
non-strict, then choosing a new function would let you realize that better
default. In contrast, by adding a new argument to the existing function,
the function you use will forever have the less preferred default.

In terms of what is a better default, I would say strict is better because
errors can’t pass silently: If errors occur, you can always change the
flag. But you would be doing that explicitly.

—Chris

On Fri, May 15, 2020 at 6:57 AM Paul Ganssle  wrote:

> I'm on the fence about using a separate function vs. a keyword argument
> (I think there is merit to both), but one thing to note about the
> separate function suggestion is that it makes it easier to write
> backwards compatible code that doesn't rely on version checking. With
> `itertools.zip_strict`, you can do some graceful degradation like so:
>
> try:
> from itertools import zip_strict
> except ImportError:
> zip_strict = zip
>
> Or provide fallback easily:
>
> try:
> from itertools import zip_strict
> except ImportError:
> def zip_strict(*args):
> yield from zip(*args)
> for arg in args:
> if next(arg, None):
>  raise ValueError("At least one input terminated early.")
>
> There's an alternate pattern for the kwarg-only approach, which is to
> just try it and see:
>
> try:
> zip(strict=True)
> HAS_ZIP_STRICT = True
> except TypeError:
> HAS_ZIP_STRICT = False
>
> But I would say it's considerably less idiomatic.
>
> Just food for thought here. In the long run this doesn't matter, because
> eventually 3.9 will fall out of everyone's support matrices and these
> workarounds will become obsolete anyway.
>
> Best,
> Paul
>
> On 5/15/20 5:20 AM, Stephen J. Turnbull wrote:
> > Brandt Bucher writes:
> >
> >  > Still agreed. But I think they would be *better* served by the
> >  > proposed keyword argument.
> >  >
> >  > This whole sub-thread of discussion has left me very confused. Was
> >  > anything unclear in the PEP's phrasing here?
> >
> > I thought it was quite clear.  Those of us who disagree simply
> > disagree.  We prefer to provide it as a separate function.  Just move
> > on, please; you're not going to convince us, and we're not going to
> > convince you.  Leave it to the PEP Delegate or Steering Council.
> >
> >  > I wouldn't confuse "can" and "should" here.
> >
> > You do exactly that in arguing for your preferred design, though.
> >
> > We could implement the strictness test with an argument to the zip
> > builtin function, but I don't think we should.  I still can't think of
> > a concrete use case for it from my own experience.  Of course I
> > believe concrete use cases exist, but that introspection makes me
> > suspicious of the claim that this should be a builtin feature, with
> > what is to my taste an ugly API.
> >
> > Again, I don't expect to convince you, and you shouldn't expect to
> > convince me, at least not without more concrete and persuasive use
> > cases than I've seen so far.
> >
> > Steve
> > ___
> > Python-Dev mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
> > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > Message archived at
> https://mail.python.org/archives/list/[email protected]/message/6NQZIDVMGPXA5QJWTKWJFZUUUAYQAOH4/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/A4UGQRMKUZDBHEE4AFJ4PL6AUUTAPF7N/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/K37A3BFMDWVUHKJNH6O36ANHIMNLPQKE/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-15 Thread David Mertz 
I'm a little frustrated by the tone in which the PEP dismisses the option
that is most supported in the discussion. It fine for Brandt to have a
different preference himself, but I think it ought to be presented more
neutrally.

On Fri, May 15, 2020, 10:20 AM Steven D'Aprano

> 1. +1 itertools.zip_strict function
> 2. +1 zip.strict(*args)
> 3. +1 zip(*args, mode='strict')  # mode='shortest' by default
> 4. +0 zip(*args, strict=True)
>

Mostly I agree with Steven on relative preference:

itertools.zip_strict() +1
zip.strict() +0.5
zip(mode='strict') +0
zip(strict=True) -0.5

Fwiw, I don't think it changes my order, but 'strict' is a better word than
'equal' in all those places. I'd subtract 0.1 from each of those votes if
they used "equal".


>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/GWLKNRJFYSSLATPFNTR6DJQB55QJOZR3/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-15 Thread Paul Moore 
On Fri, 15 May 2020 at 16:01, David Mertz  wrote:
>
> I'm a little frustrated by the tone in which the PEP dismisses the option 
> that is most supported in the discussion. It fine for Brandt to have a 
> different preference himself, but I think it ought to be presented more 
> neutrally.

Agreed. The PEP gives the impression that consensus was reached, but I
don't think that's the case. My feeling is that opinions are rather
evenly split between the approach in the PEP and an itertools
function. I also feel that proposing an itertools function would have
been a *lot* less controversial, so the tone in the PEP feels a little
like it's defending a weak position by aggressively opposing
alternatives. After all, one of the benefits of an itertools function
is that it probably wouldn't have needed a PEP in the first place!

Actually, looking at the reasons for rejection of the itertools option
in the PEP:

> It seems that a great deal of the motivation driving this alternative is that 
> zip_longest already exists in itertools.

Nope, the biggest motivation is that an itertools addition would have
been *significantly less controversial*.

Paul
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/MAWWEVC3XR5O2NPRLLYXTLL6OPDRBPF4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-15 Thread Antoine Pitrou 
On Fri, 15 May 2020 10:46:25 -0400
David Mertz  wrote:
> 
> > 1. +1 itertools.zip_strict function
> > 2. +1 zip.strict(*args)
> > 3. +1 zip(*args, mode='strict')  # mode='shortest' by default
> > 4. +0 zip(*args, strict=True)
> >  
> 
> Mostly I agree with Steven on relative preference:
> 
> itertools.zip_strict() +1
> zip.strict() +0.5
> zip(mode='strict') +0
> zip(strict=True) -0.5

For me:

* zip(strict=True)   +1
* zip(mode='strict') -0
* itertools.zip_strict() -0.5
* zip.strict()   -1  (but really, I'd like to make this -1e10)

Regards

Antoine.

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/65FIPE2EYPK4P5PK7H2NL6KIWBV5U7R5/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-15 Thread Antoine Pitrou 
On Fri, 15 May 2020 06:06:00 -
"Brandt Bucher"  wrote:

> Ethan Furman wrote:
> > Can you do those with _pydecimal?  If performance were an issue anywhere I 
> > would expect to see it with number crunching.  
> 
> No difference, probably because those methods look like they spend most of 
> their time doing string manipulation:
[ snip micro-benchmarks ]

And in any case, people who are concerned about performance should use
the C decimal accelerator, which is the default.

Here is your micro-benchmark with _pydecimal (which is the pure Python
fallback):

  $ python3.8 -m pyperf timeit -s "$PYPERFSETUP" "$PYPERFRUN"
  .
  Mean +- std dev: 35.4 us +- 1.1 us

Here is the same micro-benchmark with decimal (which loads the C
accelerator by default):

  $ python3.8 -m pyperf timeit -s "$PYPERFSETUP" "$PYPERFRUN"
  .
  Mean +- std dev: 471 ns +- 12 ns

Even if you were losing performance on those 35.4us it wouldn't make
sense to complain about it.

Regards

Antoine.


___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/3ZQVQIGLAOFB47JXYHBVNIKUTOI2N7KH/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-15 Thread Chris Angelico 
On Sat, May 16, 2020 at 1:54 AM Antoine Pitrou  wrote:
>
> On Fri, 15 May 2020 10:46:25 -0400
> David Mertz  wrote:
> >
> > > 1. +1 itertools.zip_strict function
> > > 2. +1 zip.strict(*args)
> > > 3. +1 zip(*args, mode='strict')  # mode='shortest' by default
> > > 4. +0 zip(*args, strict=True)
> > >
> >
> > Mostly I agree with Steven on relative preference:
> >
> > itertools.zip_strict() +1
> > zip.strict() +0.5
> > zip(mode='strict') +0
> > zip(strict=True) -0.5
>
> For me:
>
> * zip(strict=True)   +1
> * zip(mode='strict') -0
> * itertools.zip_strict() -0.5
> * zip.strict()   -1  (but really, I'd like to make this -1e10)
>

Since we're posting:

itertools.zip_strict() +1
zip.strict() +0.1
zip(strict=True) -0.5
zip(mode='strict') -1

ChrisA
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/JFPAP6TKMYOJNLVRN52RPN6432FDY2N4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-15 Thread Rhodri James 

On 15/05/2020 16:56, Chris Angelico wrote:

On Sat, May 16, 2020 at 1:54 AM Antoine Pitrou  wrote:


On Fri, 15 May 2020 10:46:25 -0400
David Mertz  wrote:



1. +1 itertools.zip_strict function
2. +1 zip.strict(*args)
3. +1 zip(*args, mode='strict')  # mode='shortest' by default
4. +0 zip(*args, strict=True)



Mostly I agree with Steven on relative preference:

itertools.zip_strict() +1
zip.strict() +0.5
zip(mode='strict') +0
zip(strict=True) -0.5


For me:

* zip(strict=True)   +1
* zip(mode='strict') -0
* itertools.zip_strict() -0.5
* zip.strict()   -1  (but really, I'd like to make this -1e10)



Since we're posting:

itertools.zip_strict() +1
zip.strict() +0.1
zip(strict=True) -0.5
zip(mode='strict') -1


Well, if it's what all the cool kids are doing...

* itertools.zip_strict() +1
* zip.strict() +0
* zip(mode='strict') -0
* zip(strict=True) -1

The middle two would be weird if zip_longest doesn't get folded in 
eventually, which might push them (more) negative.



--
Rhodri James *-* Kynesim Ltd
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/VMJUFQMW2IGR5B73MKRJDPLSR72YROXB/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-15 Thread Eric V. Smith 

On 5/15/2020 11:56 AM, Chris Angelico wrote:

On Sat, May 16, 2020 at 1:54 AM Antoine Pitrou  wrote:

On Fri, 15 May 2020 10:46:25 -0400
David Mertz  wrote:

1. +1 itertools.zip_strict function
2. +1 zip.strict(*args)
3. +1 zip(*args, mode='strict')  # mode='shortest' by default
4. +0 zip(*args, strict=True)


Mostly I agree with Steven on relative preference:

itertools.zip_strict() +1
zip.strict() +0.5
zip(mode='strict') +0
zip(strict=True) -0.5

For me:

* zip(strict=True)   +1
* zip(mode='strict') -0
* itertools.zip_strict() -0.5
* zip.strict()   -1  (but really, I'd like to make this -1e10)


Since we're posting:

itertools.zip_strict() +1
zip.strict() +0.1
zip(strict=True) -0.5
zip(mode='strict') -1


itertools.zip_strict() +1
zip.strict() +0
zip(strict=True) -0
zip(mode='strict') -1

I don't particularly care for "strict", though. It doesn't seem specific enough, and doesn't say 
"they iterators must return the same number of items" to me. I sort of liked "equal" 
better, but not so much to make a big stink about it.

Also: The PEP says "At most one additional item may be consumed from one of the iterators when compared 
to normalzip  usage." I think this should be prefaced with "If ValueError is raised ...". 
Also, why does it say "at most one additional item". How could it ever be less than one?

Eric

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/UM6Q4ZUDM4F2SHIY6ZGL6BABA44GFPGA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Summary of Python tracker Issues

2020-05-15 Thread Python tracker 

ACTIVITY SUMMARY (2020-05-08 - 2020-05-15)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7468 ( +9)
  closed 44917 (+60)
  total  52385 (+69)

Open issues with patches: 2996 


Issues opened (44)
==

#35967: Better platform.processor support
https://bugs.python.org/issue35967  reopened by lemburg

#40257: Improve the use of __doc__ in pydoc
https://bugs.python.org/issue40257  reopened by gvanrossum

#40567: asyncio.StreadReader `async for line in reader` is not doc
https://bugs.python.org/issue40567  opened by socketpair

#40568: Modify -c command-line option to accept multiple inputs
https://bugs.python.org/issue40568  opened by rhettinger

#40569: Add optional weights to random.sample()
https://bugs.python.org/issue40569  opened by rhettinger

#40572: [subinterpreters] Support basic asynchronous cross-interpreter
https://bugs.python.org/issue40572  opened by eric.snow

#40573: inspect.iscorutinefunction() returns False for unittest.mock.A
https://bugs.python.org/issue40573  opened by moriyoshi

#40576: Align docs for list.sort, sorted, and on the website
https://bugs.python.org/issue40576  opened by sxlijin

#40579: Second argument to iterator.next not described
https://bugs.python.org/issue40579  opened by Andrew Black

#40583: Runtime type annotation mutation leads to inconsistent behavio
https://bugs.python.org/issue40583  opened by ethereon

#40586: Pydoc should support https for hyperlinks.
https://bugs.python.org/issue40586  opened by owebeeone

#40587: [regression] inspect.getdoc not returning docstring.
https://bugs.python.org/issue40587  opened by mbussonn

#40588: Creating Virtual Environments Does Not Work (Not Creating Fold
https://bugs.python.org/issue40588  opened by Shengjun Zhu

#40590: test_subprocess stuck on Windows, x64
https://bugs.python.org/issue40590  opened by Dima.Tisnek

#40592: `Shutil.which` incosistent with windows's `where`
https://bugs.python.org/issue40592  opened by alkuzad

#40594: urljoin since 3.5 incorrectly filters out double slashes
https://bugs.python.org/issue40594  opened by David Bell

#40595: AttributeError from type annotation
https://bugs.python.org/issue40595  opened by robieta

#40597: generated email message exceeds RFC-mandated limit of 998 char
https://bugs.python.org/issue40597  opened by ivyl

#40600: Add an option to disallow creating more than one instance of a
https://bugs.python.org/issue40600  opened by vstinner

#40601: [C API] Hide static types from the limited C API
https://bugs.python.org/issue40601  opened by vstinner

#40603: slice not hashable
https://bugs.python.org/issue40603  opened by Will Bradshaw

#40604: Regression in 3.8.3rc1 - error in tests run via doctest
https://bugs.python.org/issue40604  opened by casevh

#40605: «python»: Aucun fichier ou dossier de ce type
https://bugs.python.org/issue40605  opened by sab1703

#40606: Copy property return annotations to __annotations__
https://bugs.python.org/issue40606  opened by Eric Wieser

#40607: asyncio.wait_for should reraise future exception even if timeo
https://bugs.python.org/issue40607  opened by Roman Skurikhin

#40608: PY3.8 GC segfault  (Py_TRASHCAN_SAFE_BEGIN/END are not backwar
https://bugs.python.org/issue40608  opened by iritkatriel

#40611: Add MAP_POPULATE to the mmap library
https://bugs.python.org/issue40611  opened by Ethan Steinberg

#40612: Make traceback module's formatting of SyntaxError more similar
https://bugs.python.org/issue40612  opened by gvanrossum

#40614: ast.parse doesn't respect feature_version for debug f-strings
https://bugs.python.org/issue40614  opened by hauntsaninja

#40616: Add `asyncio.BufferQueue`
https://bugs.python.org/issue40616  opened by lig

#40617: sqlite3: expose sqlite3_create_window_function
https://bugs.python.org/issue40617  opened by iljau

#40620: Range tutorial shorthand could be made clearer
https://bugs.python.org/issue40620  opened by [email protected]

#40622: Using VS2019 to automatically build Python3 and Runtest and it
https://bugs.python.org/issue40622  opened by Lin

#40623: JSON streaming
https://bugs.python.org/issue40623  opened by phr

#40624: add support for != (not-equals) in ElementTree XPath
https://bugs.python.org/issue40624  opened by Antony.Lee

#40625: Autogenerate signature for METH_NOARGS and perhaps METH_O exte
https://bugs.python.org/issue40625  opened by Antony.Lee

#40626: application/x-hdf5 mime type missing from mimetypes library
https://bugs.python.org/issue40626  opened by schwabm

#40628: sockmodule.c: sock_connect vs negative errno values...
https://bugs.python.org/issue40628  opened by icculus

#40629: Error MSB4086 (numeric comparison)
https://bugs.python.org/issue40629  opened by veganaiZe

#40630: tracemalloc: allow resetting peak memory metric without touchi
https://bugs.python.org/issue40630  opened by huonw

#40632: AttributeE

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

2020-05-15 Thread Paul Moore 
[Cut the previous votes because someone's quoting didn't survive my
email client and I can't be bothered fixing it]

If everyone else is doing it...

itertools.zip_strict() +1
zip(strict=True) -0
zip.strict() -0.5
zip(mode='strict') -1

Paul
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/4YDZH7E6IYDI4EQJPUREUZAYVQE5ITI6/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-15 Thread Henk-Jaap Wagenaar 
I'll join in with the fun...

zip(strict=True) +1
itertools.zip_strict() +0
zip(mode='strict') -1
zip.strict() -1

On Fri, 15 May 2020 at 19:12, Paul Moore  wrote:

> [Cut the previous votes because someone's quoting didn't survive my
> email client and I can't be bothered fixing it]
>
> If everyone else is doing it...
>
> itertools.zip_strict() +1
> zip(strict=True) -0
> zip.strict() -0.5
> zip(mode='strict') -1
>
> Paul
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/4YDZH7E6IYDI4EQJPUREUZAYVQE5ITI6/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/LY6NYA4NQKE37XILEIQD3KZQ4FQ3BEN5/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-15 Thread Guido van Rossum 
On Fri, May 15, 2020 at 11:57 Henk-Jaap Wagenaar 
wrote:

> I'll join in with the fun...
>
> zip(strict=True) +1
> itertools.zip_strict() +0
> zip(mode='strict') -1
> zip.strict() -1
>


Those are exactly how I would vote.
-- 
--Guido (mobile)
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/TYJW4KPCICOEO6TJQXDMAVBXRMH3TY6C/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-15 Thread Gregory P. Smith 
On Fri, May 15, 2020 at 11:55 AM Henk-Jaap Wagenaar <
[email protected]> wrote:

> I'll join in with the fun...
>
> zip(strict=True) +1
> itertools.zip_strict() +0
>

Agreed.  The best way to reduce accidental incorrect use of the builtin is
to make the builtin capable of doing what a people want directly without
having to go discover something in a module somewhere.

OTOH so long as zip's docstring that shows up to people from interactive
help, pydoc, and hover/alt/meta text in fancier IDEs mentions the caveat
and the way to get the strict behavior, either of these two should be
sufficient.  I'm pushing forward with a pure documentation update in
https://github.com/python/cpython/pull/20118 suitable for 3.8 - it doesn't
mention the way to get the other behavior as that isn't settled or short
yet, just makes it more obvious what the actual behavior is.

-gps
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/ZWQJJXHQTHAVIQXU4ZJWO2QUFAWFA6ZV/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-15 Thread David Mertz 
On Fri, May 15, 2020 at 12:55 PM Eric V. Smith  wrote:

> Also: The PEP says "At most one additional item may be consumed from one
> of the iterators when compared to normal zip usage." I think this should
> be prefaced with "If ValueError is raised ...". Also, why does it say "at
> most one additional item". How could it ever be less than one?
>

This struck me as strange also.  I mean, the wording can be improved to
clarify "if error."

But more significantly, it seems like it cannot conceivably be true.  If
might be "At most one additional item from EACH of the iterators."

If I do zip_strict(a, b, c, d, e) and "e" is the one that is shorter, how
could any algorithm ever avoid consuming one extra item of a, b, c, and d
each?!


-- 
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.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/6DAOB62ODEGJZYBTGINWPV5R3U4EDOWX/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-15 Thread MRAB 

On 2020-05-15 20:36, David Mertz wrote:
On Fri, May 15, 2020 at 12:55 PM Eric V. Smith > wrote:


Also: The PEP says "At most one additional item may be consumed from
one of the iterators when compared to normal zip usage." I think
this should be prefaced with "If ValueError is raised ...". Also,
why does it say "at most one additional item". How could it ever be
less than one?


This struck me as strange also.  I mean, the wording can be improved to 
clarify "if error."


But more significantly, it seems like it cannot conceivably be true.  If 
might be "At most one additional item from EACH of the iterators."


If I do zip_strict(a, b, c, d, e) and "e" is the one that is shorter, 
how could any algorithm ever avoid consuming one extra item of a, b, c, 
and d each?!



Well, it does say "when compared to normal zip usage".

The normal zip would consume an item of a, b, c, and d. If e is 
exhausted, then zip would just stop, but zip_strict would raise 
ValueError. There would be no difference in the number of items consumed 
but not used.

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/5B26LEJYDRIFCP3ETEAWLJJFV76PUKQ4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-15 Thread Eric V. Smith 
I fear that my comment on some text in the PEP was lost amidst the 
voting, so I'm repeating it here. This will probably screw up some 
threading, but this is the oldest message I have to reply to.


The PEP says "At most one additional item may be consumed from one of 
the iterators when compared to normal zip usage." I think this should be 
prefaced with "If ValueError is raised ...". Also, why does it say "at 
most one additional item". How could it ever be less than one?


And I'm not sure I'd say "normal zip usage", maybe "the existing builtin 
zip function".


Eric
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/ZEY2QHBSILZZHL7ISYZTHC4KHJ4JTBI7/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-15 Thread Henk-Jaap Wagenaar 
On Fri, 15 May 2020 at 21:50, Eric V. Smith  wrote:

> I fear that my comment on some text in the PEP was lost amidst the
> voting, so I'm repeating it here. This will probably screw up some
> threading, but this is the oldest message I have to reply to.
>
> The PEP says "At most one additional item may be consumed from one of
> the iterators when compared to normal zip usage." I think this should be
> prefaced with "If ValueError is raised ...". Also, why does it say "at
> most one additional item". How could it ever be less than one?
>

It seems to me, looking at the Python implementation in the PEP (not the
current or C implementation) that the crux is here:

except StopIteration:
if not strict:
return
 if items:
i = len(items) + 1
raise ValueError(f"zip() argument {i} is too short")

So if it is not strict, it will return/stop consuming iterators. If it is
strict but it runs out *not* on the first iterator it will also not consume
from another iterator?


> And I'm not sure I'd say "normal zip usage", maybe "the existing builtin
> zip function".
>

Depends on where we end up I guess, if we go with what Brandt' PEP says
(makes sense to keep internally consistent) I'd say "zip without the
strict=True flag" or similar.

>
> Eric
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/ZEY2QHBSILZZHL7ISYZTHC4KHJ4JTBI7/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/ASL5UENQJVANGZQRQEFKRIC3RERPN6XZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Core Workflow change: new commit to previously approved PR now requires re-review

2020-05-15 Thread Mariatta 
X-post to python-committers, python-dev, and core-workflow mailing list

I have just deployed a change to bedevere-bot to address the security
concern related to automerging.(
https://github.com/python/core-workflow/issues/325)

Previously, if core dev has approved the PR and applied the "automerge"
label, the PR will be automatically merged as soon as all the required CI
checks passed. If the PR author added another commit after the PR has been
approved but before the automerge happened, the additional commit will get
merged in without additional review.

Now, if there is a new commit after the PR has been approved, it will not
be automerged until the the core dev re-reviews it. bedevere will remove
the "awaiting merge" label and apply the "awaiting core review" label.

Hope this all makes sense. And if you see any of the bot misbehaving,
please open a ticket either in core-workflow repo or in the bot's own repo.

Thanks.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/KQZFJ3GJWMQ6TBNIYC6T2ZVAXBCV3KXS/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-15 Thread David Mertz 
Ok. That's true. It's technically correct as phrased. I glossed over the
"compared to" aspect. I still think it could be made more clear.

On Fri, May 15, 2020, 4:40 PM MRAB  wrote:

> On 2020-05-15 20:36, David Mertz wrote:
> > On Fri, May 15, 2020 at 12:55 PM Eric V. Smith  > > wrote:
> >
> > Also: The PEP says "At most one additional item may be consumed from
> > one of the iterators when compared to normal zip usage." I think
> > this should be prefaced with "If ValueError is raised ...". Also,
> > why does it say "at most one additional item". How could it ever be
> > less than one?
> >
> >
> > This struck me as strange also.  I mean, the wording can be improved to
> > clarify "if error."
> >
> > But more significantly, it seems like it cannot conceivably be true.  If
> > might be "At most one additional item from EACH of the iterators."
> >
> > If I do zip_strict(a, b, c, d, e) and "e" is the one that is shorter,
> > how could any algorithm ever avoid consuming one extra item of a, b, c,
> > and d each?!
> >
> Well, it does say "when compared to normal zip usage".
>
> The normal zip would consume an item of a, b, c, and d. If e is
> exhausted, then zip would just stop, but zip_strict would raise
> ValueError. There would be no difference in the number of items consumed
> but not used.
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/5B26LEJYDRIFCP3ETEAWLJJFV76PUKQ4/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/IJZJKTYGKEX7MFY3IPSJ6TGDOKX5FW6L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [core-workflow] Core Workflow change: new commit to previously approved PR now requires re-review

2020-05-15 Thread Daniel Scott via Python-Dev 


Sent from Yahoo Mail on Android 
 
  On Fri, May 15, 2020 at 6:33 PM, Mariatta wrote:   
X-post to python-committers, python-dev, and core-workflow mailing list
I have just deployed a change to bedevere-bot to address the security concern 
related to automerging.(https://github.com/python/core-workflow/issues/325)
Previously, if core dev has approved the PR and applied the "automerge" label, 
the PR will be automatically merged as soon as all the required CI checks 
passed. If the PR author added another commit after the PR has been approved 
but before the automerge happened, the additional commit will get merged in 
without additional review. 
Now, if there is a new commit after the PR has been approved, it will not be 
automerged until the the core dev re-reviews it. bedevere will remove the 
"awaiting merge" label and apply the "awaiting core review" label. 
Hope this all makes sense. And if you see any of the bot misbehaving, please 
open a ticket either in core-workflow repo or in the bot's own repo.
Thanks.


___
core-workflow mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/core-workflow.python.org/
This list is governed by the PSF Code of Conduct: 
https://www.python.org/psf/codeofconduct
  
___
core-workflow mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/core-workflow.python.org/
This list is governed by the PSF Code of Conduct: 
https://www.python.org/psf/codeofconduct
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/OF227DTX6JLLWSJ7GSNEKEH6ZXTHVYHE/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-15 Thread Brandt Bucher 
In the last 24 hours, this thread has grown a bit beyond my capacity to 
continue several different lines of discussion with each individual. I count 22 
messages from 14 different people since my last reply, and I assure you that 
I've carefully read each response and am considering them as I work on the next 
draft.

I'd like to thank everyone who took the time to read the PEP and provide 
thoughtful, actionable feedback here!

Brandt
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/7V7A2C4EXCEJD2Y2Q3OEQBZYKGJI5QVU/
Code of Conduct: http://python.org/psf/codeofconduct/