Fwd: New suggested built in keyword: do

I think that the keyword do would solve problems that occur when people want a simple way to run a command over an iterable but they dont want to store the data.
example:
do print(x) for x in range(50) --------- this above command will not return anything and will just run the command that is underlined over a generator. thus running a command comprehension or do comprehension. this will stop people from using the list comprehension to run an iterable through a function when they dont want to return anything. ( Specifically if memory is something we would want to conserve, such as in multithreaded web applications. )

I don't see how this is different to just:
for x in range(50): print(x) Can you elaborate further? Jamie
On Jun 8 2018, at 3:12 pm, Randy Diaz randiaz95@gmail.com wrote:
I think that the keyword do would solve problems that occur when people want a simple way to run a command over an iterable but they dont want to store the data. example:
do print(x) for x in range(50)
this above command will not return anything and will just run the command that is underlined over a generator. thus running a command comprehension or do comprehension. this will stop people from using the list comprehension to run an iterable through a function when they dont want to return anything. ( Specifically if memory is something we would want to conserve, such as in multithreaded web applications. )
Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On 2018-06-08 15:12, Randy Diaz wrote:
I think that the keyword do would solve problems that occur when people want a simple way to run a command over an iterable but they dont want to store the data.
example:
do print(x) for x in range(50) --------- this above command will not return anything and will just run the command that is underlined over a generator. thus running a command comprehension or do comprehension. this will stop people from using the list comprehension to run an iterable through a function when they dont want to return anything. ( Specifically if memory is something we would want to conserve, such as in multithreaded web applications. )
How is that better than:
for x in range(50): print(x)
(if you want it to be a single line)?

Given that an exhaust method for generators didn't make it, I dont think a keyword has more chance. For reference, that exhaust method would have looked like:
(print (x) for x in range(50)).exhaust()
and be defined as:
def exhaust(self): for _ in self: pass
Also, there was some more involved method that did it in less characters, having to do with queues of length 0 or something.

What about just supporting filtering syntax at the top level?
for x range(50) if x % 2: print(x)
It's a minor syntactic change which is very flexible and consistent with the existing comprehension syntax. Could even extend to allow multiple iterators as per a comprehension
On Fri, 8 Jun 2018, 15:59 Jacco van Dorp, j.van.dorp@deonet.nl wrote:
Given that an exhaust method for generators didn't make it, I dont think a keyword has more chance. For reference, that exhaust method would have looked like:
(print (x) for x in range(50)).exhaust()
and be defined as:
def exhaust(self): for _ in self: pass
Also, there was some more involved method that did it in less characters, having to do with queues of length 0 or something. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Jamie Willis wrote:
What about just supporting filtering syntax at the top level?
for x range(50) if x % 2: print(x)
It would be more general and probably easier to support this:
for x in range(50): if x % 2: print(x)
i.e. just relax the requirement that a statement following on the same line after a colon must be a simple statement.

On Fri, Jun 8, 2018, 10:12 Randy Diaz randiaz95@gmail.com wrote:
I think that the keyword do would solve problems that occur when people want a simple way to run a command over an iterable but they dont want to store the data.
example:
do print(x) for x in range(50)
this above command will not return anything and will just run the command that is underlined over a generator. thus running a command comprehension or do comprehension. this will stop people from using the list comprehension to run an iterable through a function when they dont want to return anything. ( Specifically if memory is something we would want to conserve, such as in multithreaded web applications. )
I would prefer some some syntax for consuming iterators in a general way, such as
* = (x for x in y)

On Fri, Jun 08, 2018 at 10:12:01AM -0400, Randy Diaz wrote:
I think that the keyword do would solve problems that occur when people want a simple way to run a command over an iterable but they dont want to store the data.
Why does it have to be a keyword?
I like this pair of functions:
def do(func, iterable, **kwargs): for x in iterable: func(x, **kwargs)
def star(func, iterable, **kwargs): for x in iterable: func(*x, **kwargs)
do.star = star del star
Here's an example in use:
py> do(print, [(1, 2), (3, 4), (5, 6, 7, 8)], sep='-', end='*\n') (1, 2)* (3, 4)* (5, 6, 7, 8)* py> do.star(print, [(1, 2), (3, 4), (5, 6, 7, 8)], sep='-', end='*\n') 1-2* 3-4* 5-6-7-8*
Customize to your taste, and put them in your own personal toolbox.

The benefit of list, dict, and set comprehensions and generator expressions is that they evaluate, as opposed to simply exec. The purpose of making them one-liners is to allow them to be assigned to a variable or passed as an argument.
If you're not assigning or passing, then why not use a newline character? "Sparse is better than dense."
On Friday, June 8, 2018 at 7:13:07 AM UTC-7, Randy Diaz wrote:
I think that the keyword do would solve problems that occur when people want a simple way to run a command over an iterable but they dont want to store the data.
example: do print(x) for x in range(50)
participants (9)
-
Greg Ewing
-
Jacco van Dorp
-
Jamie Willis
-
Jamie Willis
-
Michael Selik
-
MRAB
-
Randy Diaz
-
Steven D'Aprano
-
Todd