I know this is not the point of this thread, but when i saw: ``` numbers = (i for i in range(10)) assert 3 in numbers next(numbers) # 4! ``` I was totally surprised that generator expressions support `in` -- WTF? they very much are NOT containers!
And, in fact, all iterators support `in` -- wow, just wow. I know this is not going to change, but it strikes me as a greater source of mysterious bugs than not getting an error from iterating an exhausted iterator. Getting back OT: The distinction between iterators and containers is simply something that you need to learn -- it's an inevitable consequence of the benefits of iterators. And the original example is an easy one -- Python supports both list comprehensions and generator comprehensions -- you really need to know which to use when. -CHB On Tue, Jun 13, 2023 at 4:18 PM Chris Angelico <ros...@gmail.com> wrote: > On Wed, 14 Jun 2023 at 09:05, BoppreH via Python-ideas > <python-ideas@python.org> wrote: > > > > @ChrisA: There are already flags for enabling warnings on dangerous > bytearray comparisons[1] or relying on locale-dependent encodings[2], not > to mention a whole Development Mode flag[3] that adds extra checks. Some of > those checks affect fewer people than my proposal. A "warn on reused > generators" flag would fit right in, maintain backwards compatibility, and > help some people (admittedly less than an opt-out one). > > > > Citation needed, how do you calculate that they affect fewer people > than your proposal? The byte/str comparison warning relates to Py2/Py3 > changes, which affected huge numbers of people; locale-dependent > encodings affect everyone whose systems default to those encodings; > and I don't know what the debug build does exactly, but it's > specifically meant to cover things that are too expensive to check for > normally. > > Also, question: Would your proposal even be useful to people if they > had to run Python with a special parameter to get it? Wouldn't it be > just as easy to shadow iter(), like I have already suggested multiple > times as a much better way to do this? > > > And then Chris' messages started rolling in. > > Backward compatibility is WAY more important than a lot of proposals > seem to acknowledge. You're welcome to hate me for saying it, but > frankly, you're also welcome to ignore my posts. I don't have to prove > anything to you; the onus is on you to demonstrate the value of your > proposal, and at the moment, you've shown a benefit in a very small > number of cases, contrasted with a potentially huge number of > situations where this would create a spurious warning. > > Blaming me for the pushback is a tad unfair. But that's your prerogative. > > 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/RHQWRDV46TPPHTVD5ZRYFHILQM6PZ53T/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ 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/RVFCHTB5MNJ5HIY2UEK3HURMGSPVFNOZ/ Code of Conduct: http://python.org/psf/codeofconduct/
