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

[David Mertz]

On Tue, Jun 2, 2020, 9:41 AM Steve Dower

> > As is, I use islice() or a break inside a loop, but that hypothetical
> parameter might be a helpful
> > convenience.
>
> Besides, "zip(iter1, iter2, range(5))" is the same length once you include
> the extra unpack, plus it works well with earlier versions.


Oh yeah. I've done that too. For whatever reason, I think I used to use the
extra range, and nowadays I'm more likely to use islice(). I have
absolutely no argument why one style or the other is better, just my habit
has changed.

In any case, I'm not advocating for truncate=5 behavior. Merely agreeing
that the word truncate is not less ambiguous than the word strict. That's
not even saying I prefer strict to truncate; itertools.zip_strict() remains
my preference. But I could learn either parameter choice easily enough.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3XIS5HCXMEZZUGWBPNT2EDZMQFLN3YQN/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Steven D'Aprano]

On Tue, Jun 02, 2020 at 08:52:46PM +1000, Nick Coghlan wrote:

> > Truncate at what?
> >
> > - some maximum length;
> > - some specific element;
> > - at the shortest input.
> >
> 
> Given that the only input parameters are the iterables themselves, it's a
> stretch to even consider the first two as possibilities.

And then:

> "strict=False" doesn't tell you whether the tolerant behaviour is
> truncation or padding. "truncate=True" does.

You can't have it both ways Nick -- if the lack of additional parameters 
is enough for the user to predict that the only reasonable behaviour is 
to truncate, then the lack of additional parameters is also enough for 
them to predict that the only reasonable non-strict (tolerant) behaviour 
is to truncate at the shortest input.


[...]
> > But for the case of non-default behaviour, strict=True is a clear
> > winner. It can pretty much only mean one thing: raise an exception.
> >
> 
> But raise an exception when? In the context of this discussion, we know we
> mean "strict length checking, raising an exception for inconsistent
> lengths".
> 
> But "strict" on its own doesn't convey that - we could be requesting strict
> runtime type checking, for example, where each iterable is expected to keep
> producing items of the same type as was produced for the first tuple. Or we
> could be requesting a check that the values in the tuple aren't "None".

If you are going to propose that users might imagine a hypothetical 
check that raises if any item is None, well, isn't that *precisely* the 
sentinel check I gave above that you blithly dismissed as "a stretch"?

If it's a stretch for me, it's a stretch for you too.

Ultimately, bikeshedding on the name truncate versus strict versus equal 
versus shortest versus ... is quibbling. Everyone who reads the 
tooltips, assuming they even see them, is going to take something 
different from it. Some will think "truncate what, the tuples?" and some 
will think "strict about what?".

Ultimately the tooltips are no substitute for reading the docs. If you 
don't know what zip does, you cannot interpret what it means for zip to 
truncate or be strict. No one single word is going to communicate 
everything we need to communicate. Function and parameter names are 
mnemonics, not documentation.

So on that note, and in regard only to the choice between "strict" 
versus "truncate" etc, I'm going to bow out: call it what you will. I've 
got a bigger problem with the use of a boolean flag than the name.


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

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

[Steve Dower]

On 02Jun2020 1430, David Mertz wrote:
On Tue, Jun 2, 2020 at 8:07 AM Chris Angelico > wrote:


 > Given that the only input parameters are the iterables
themselves, it's a stretch to even consider the first two as
possibilities.

Why? I can conceivably imagine that zip(iter1, iter2, truncate=5)
would consume at most 5 elements from each iterable. It's not much of
a stretch. It doesn't happen to be what's proposed, but it's a
reasonable interpretation. (Though then the default would probably be
truncate=None to not truncate.)


This was exactly my thought, that Chris wrote very well.  I can easily 
imagine a 'truncate=5' behavior.  In fact, if it existed, it is 
something I would have used multiple times.  As is, I use islice() or a 
break inside a loop, but that hypothetical parameter might be a helpful 
convenience.


However, it is indeed NOT the current proposal or discussion.


Besides, "zip(iter1, iter2, range(5))" is the same length once you 
include the extra unpack, plus it works well with earlier versions.


Cheers,
Steve


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

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

[David Mertz]

On Tue, Jun 2, 2020 at 8:07 AM Chris Angelico  wrote:

> > Given that the only input parameters are the iterables themselves, it's
> a stretch to even consider the first two as possibilities.
>
> Why? I can conceivably imagine that zip(iter1, iter2, truncate=5)
> would consume at most 5 elements from each iterable. It's not much of
> a stretch. It doesn't happen to be what's proposed, but it's a
> reasonable interpretation. (Though then the default would probably be
> truncate=None to not truncate.)
>

This was exactly my thought, that Chris wrote very well.  I can easily
imagine a 'truncate=5' behavior.  In fact, if it existed, it is something I
would have used multiple times.  As is, I use islice() or a break inside a
loop, but that hypothetical parameter might be a helpful convenience.

However, it is indeed NOT the current proposal or discussion.

-- 
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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZP3VU52SKEVEY5LHTHQKOEUYLEWNRKAV/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

On Tue, Jun 2, 2020 at 8:55 PM Nick Coghlan  wrote:
>
>
>
> On Tue., 2 Jun. 2020, 11:23 am Steven D'Aprano,  wrote:
>>
>>
>>
>> > The conceptual idea here is that the "truncate" flag name would technically
>> > be a shorter mnemonic for "truncate_silently", so clearing it gives you an
>> > exception rather enabling padding behaviour.
>> >
>> > Flipping the sense of the flag also means that "truncate=True" will appear
>> > in IDE tooltips as part of the function signature, providing significantly
>> > more information than "strict=False" would.
>>
>> "Significantly" more? I don't think so.
>>
>> Truncate at what?
>>
>> - some maximum length;
>> - some specific element;
>> - at the shortest input.
>
>
> Given that the only input parameters are the iterables themselves, it's a 
> stretch to even consider the first two as possibilities.
>

Why? I can conceivably imagine that zip(iter1, iter2, truncate=5)
would consume at most 5 elements from each iterable. It's not much of
a stretch. It doesn't happen to be what's proposed, but it's a
reasonable interpretation. (Though then the default would probably be
truncate=None to not truncate.)

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

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

[Nick Coghlan]

On Tue., 2 Jun. 2020, 11:23 am Steven D'Aprano,  wrote:

>
>
> > The conceptual idea here is that the "truncate" flag name would
> technically
> > be a shorter mnemonic for "truncate_silently", so clearing it gives you
> an
> > exception rather enabling padding behaviour.
> >
> > Flipping the sense of the flag also means that "truncate=True" will
> appear
> > in IDE tooltips as part of the function signature, providing
> significantly
> > more information than "strict=False" would.
>
> "Significantly" more? I don't think so.
>
> Truncate at what?
>
> - some maximum length;
> - some specific element;
> - at the shortest input.
>

Given that the only input parameters are the iterables themselves, it's a
stretch to even consider the first two as possibilities.




> At some point people have to read the docs, not just the tooltips. If
> you didn't know what zip does, seeing truncate=True won't mean anything
> to you. If you do know what zip does, then the parameter names are
> mnemonics, and strict=False and truncate=True provide an equal hint for
> the default behaviour:
>
> * if it's not strict, it is tolerant, stopping at the shortest;
> * if it truncates, it truncates at the shortest input.
>

"strict=False" doesn't tell you whether the tolerant behaviour is
truncation or padding. "truncate=True" does.


> For the default case, strict=False and truncate=True are pretty much
> equal in information.
>

Nope. If you don't already know that zip truncates the output by default,
"truncate=True" gives you that information, while "strict=False" doesn't.


> But for the case of non-default behaviour, strict=True is a clear
> winner. It can pretty much only mean one thing: raise an exception.
>

But raise an exception when? In the context of this discussion, we know we
mean "strict length checking, raising an exception for inconsistent
lengths".

But "strict" on its own doesn't convey that - we could be requesting strict
runtime type checking, for example, where each iterable is expected to keep
producing items of the same type as was produced for the first tuple. Or we
could be requesting a check that the values in the tuple aren't "None".


> > That improved self-documentation then becomes what I would consider the
> > strongest argument in favour of the flag-based approach:
>
> I don't think that "truncate=False" (which can mean three different
> things) is more self-documenting than `zip(*items, mode='strict')` or
> `zip_strict()` (either of which can only mean one thing).
>

As noted above, "strict" just means "check more constraints" - it's at
least as ambiguous as "don't truncate the output".

I do agree that the ambiguity of "truncate=False" is the biggest downside
of that spelling, but learning that it means "raise an exception on a
length mismatch instead of truncating the output iterator" isn't going to
be any harder than learning what strict mode means.

Cheers,
Nick.

>
>
>
> --
> Steven
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/37TI3ZEU7JZUJBERFDRRCMNI5Y3CGP7T/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NAHKEDDJGWRFL5S6FNWMYLKK7PYY4XGW/
Code of Conduct: http://python.org/psf/codeofconduct/