Re: [Python-ideas] Fwd: New suggested built in keyword: do

2018-06-08 Thread Jamie Willis
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,

Re: [Python-ideas] Fwd: New suggested built in keyword: do

2018-06-08 Thread Jamie Willis
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 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

Re: [Python-ideas] Temporary variables in comprehensions

2018-02-15 Thread Jamie Willis
of mind, wishing for variables in > comprehensions seems to me like a good indicator that your code needs > refactoring. > > Best, > > E > > On 15 February 2018 at 10:32, Jamie Willis <jw14896.2...@my.bristol.ac.uk> > wrote: > > > > I +1 this at surfa

Re: [Python-ideas] Temporary variables in comprehensions

2018-02-15 Thread Jamie Willis
I +1 this at surface level; Both Haskell list comprehensions and Scala for comprehensions have variable assignment in them, even between iterating and this is often very useful. Perhaps syntax can be generalised as: [expr_using_x_and_y for i in is x = expr_using_i for j in is y =

Re: [Python-ideas] Python 4: Concatenation

2017-06-30 Thread Jamie Willis
Just as an aside, if a concatenation operator *was* included, a suitable operator would be "++", this is the concatenation operator in languages like Haskell (for strings) and the majority of Scala cases. Alternatively "<>" is an alternative, being the monoidal append operator in Haskell, which