+1 This is just a small improvement, but worthwhile. It's intuitive IMO to be able to use similar filtering expressions to comprehensions at the top of a for loop.
Here's an example: # get the Hadoop version by scanning pyspark jars. # Vague attribution: https://stackoverflow.com/a/50242383 for path in Path("pyspark/jars")).glob("hadoop-*.jar") if not path.stem.startswith("hadoop-shaded-guava"): name, _, version = path.stem.rpartition("-") ... glob is already a filtering mechanism. It's just not *quite* flexible enough to give just the items I want. I'd like to be able to enter the loop with only file names of interest. –Michael A. Smith On Tue, Mar 1, 2022 at 21:51 Paul Bryan <pbr...@anode.ca> wrote: > 1. It aligns with existing syntax in list comprehensions and generator > expressions. > 2. In probably majority of cases it would be more readable to me; "iterate > over iterable for items meeting condition:". > 3. Could it be easier to optimize an explicit filter expression to improve > iteration performance? > > On Wed, 2022-03-02 at 13:37 +1100, Steven D'Aprano wrote: > > On Wed, Mar 02, 2022 at 02:28:33AM +0100, Svein Seldal wrote: > > for x in y if x in c: > some_op(x) > > > What does this new syntax give us that we don't already have with this? > > for x in y > if x in c: > some_op(x) > > or the other multiple ways of writing the equivalent code? > > I see no new functionality here. Is the only advantage that you save one > line and one indent level? Both are cheap. > > To be precise, one extra line in something which is already a multiline > statement is essentially insignificant, and while an extra indent level > *can* be important, if you have already used so many indents that it > becomes important, you probably should be refactoring your code. > > All I see here is adding to the complexity of the parser and the > language for no meaningful benefit. Its not even easier to read, it > crams more on one line which in real code with meaningful variable names > and a meanigful condition starts to get a bit long: > > # this line desperately needs to be split over two lines > for student in students if mean(student.grade(subject) for subject in > student.get_subjects()) > 0.8): > ... > > When I write list comprehensions with an if condition, probably 90% of > the time I end up moving the if condition to a second or even third line > of the comprehension. I expect the same will apply here. > > To save one line for maybe 10% of my for...if constructs, I don't think > it is worth the bother of adding yet another way to do it. > > > > _______________________________________________ > 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/KTM6XDMOMQW4W7XRDMG7S65EL34GXAZG/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ 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/IP3NN773LRXG7VHEPX6BV3O2NWPK462W/ Code of Conduct: http://python.org/psf/codeofconduct/
