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 firstname.lastname@example.org 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.