On Thu, Oct 14, 2021 at 1:36 AM Oscar Benjamin <oscar.j.benja...@gmail.com> wrote: > Your suggestion is that this is a bug in map() which is a fair > alternative view. Following through to its conclusion your suggestion > is that every possible function like map, filter, and all the iterator > implementations in itertools and in the wild should carefully wrap any > internal non-next function call in try/except to change any potential > StopIteration into a different exception type.
Yes, because it is the map function that is leaking StopIteration. > My view is that it would be better to have a basic primitive for > getting an element from an iterable or for advancing an iterator that > does not raise StopIteration in the first place. I would probably call > that function something like "take" rather than "first" though. The > reason I prefer introducing an alternative to next() is because I > think that if both primitives were available then in the majority of > situations next() would not be the preferred option. How will that solve anything though? You still need a way to advance an iterator and get a value from it, or get told that there is no such value. No matter what exception you choose, it will ALWAYS be possible for the same problem to occur. Exceptions like ValueError will, instead of early-aborting a map(), cause something to mistakenly think that it couldn't parse a number, or something like that. Try replacing your map() with one of my safer versions. (Or, of course, replacing your remove_header with a version that isn't itself buggy.) The problem will disappear. ChrisA _______________________________________________ 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/FGSAIJP3SHLPD5XUZBBCX2MCZIZT3IVS/ Code of Conduct: http://python.org/psf/codeofconduct/
