In close to 10 years of experience with python I have never encountered anything like this. If I need to use a list later I never do ANY assignments to it. Why would I? In the last example I would: ``` strings = ['aa', '', 'bbb', 'c’] longest = max(filter(bool, strings), key=len) n_unique = len(set(strings)) ``` And in initial example I don’t see why would I ever do this. It is very unclear what is the scenario here: ```??? numbers = (i for i in range(5)) assert 5 not in numbers sorted(numbers) ``` 1. If I wanted sorted numbers, then ValueError wouldn’t help, because I do not get sorted numbers. 2. If I wanted unmodified list and if it was modified then it is an error, your solution doesn’t work either. 3. If sorting is ok only on non-empty iterator, then just `assert sorted` after sorting. If you could give a full real-life scenario, then it might expose the problem (if it exists) better. "There should be one-- and preferably only one --obvious way to do it.” There is either: something to be improved or you are not using that "one obvious" way.
On 13 Jun 2023, at 18:05, BoppreH via Python-ideas <python-ideas@python.org> wrote:
@ChrisA: Shadowing "iter()" would only help with Barry's example.
@Jonathan: Updating documentation is helpful, but I find an automated check better. Too often the most obvious way to accomplish something silently triggers this behavior:
strings = ['aa', '', 'bbb', 'c'] strings = filter(bool, strings) # Adding this step makes n_unique always 0. longest = max(strings, key=len) n_unique = len(set(strings))
I feel like a warning here would save time and prevent bugs, and that my is_exhausted proposal, if implemented directly in the generators, is an easy way to accomplish this.
And I have to say I'm surprised by the responses. Does nobody else hit bugs like this and wish they were automatically detected? To be clear, raising ValueError is just an example; logging a warning would already be helpful, like Go's race condition detector.
-- BoppreH _______________________________________________ Python-ideas mailing list -- python-ideas@python.org <mailto:python-ideas@python.org> To unsubscribe send an email to python-ideas-leave@python.org <mailto:python-ideas-leave@python.org> https://mail.python.org/mailman3/lists/python-ideas.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/KWBFRI... <https://mail.python.org/archives/list/python-ideas@python.org/message/KWBFRI...> Code of Conduct: http://python.org/psf/codeofconduct/ <http://python.org/psf/codeofconduct/>