On 04.05.20 16:14, Steven D'Aprano wrote:
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 <st...@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.
I think it's acceptable for `zip` because it's possible to infer its
meaning without much ambiguity. I think it's reasonable to associate
`strict=True` with the process of zipping (i.e. neither with the
arguments nor the result directly). And then the only thing it could
possibly be strict about is the length of the iterables. On the other
hand my perception is probably biased by having participated in this
discussion and hence knowing already what the meaning is without having
to think about it. It would be interesting to hear from a person who
hasn't participated in this discussion what they expect from `strict=True`.
However for `map` I wouldn't associate `strict=True` with the
zipping-functionality that it provides. This is a nice feature but not
the main purpose of the function -- it would equally work without it
(requiring manual zipping). I'd associate this keyword either with the
process of mapping or the produced values. Regarding the former I could
imagine an alternative interpretation: currently `map` stops on a
`StopIteration` which is leaked by the mapping function (unlike
generators which convert this into a `RuntimeError`). So I could imagine
that `strict=True` activates this conversion also for `map`, i.e. being
strict in a sense that it accepts a `StopIteration` only from the mapped
iterator and not from the mapping function.
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)]
`truncate=True` seems to be quite clear about its behavior, but for
`truncate=False` I think it's not obvious that this raises an exception.
It just says it won't truncate on the shortest iterator but otherwise is
not explicit about its behavior. `strict` on the other hand implies an
"intervening reaction" when not playing by the rules, like an exception
being raised.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/YTCIKQTT4F3X2BK4SKOGH4QH7C4DECX5/
Code of Conduct: http://python.org/psf/codeofconduct/
