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/

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.

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.

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