On 31.01.2017 00:54, Mikhail V wrote:
Great idea :) But actually that was my idea initially, so just
breaking it into two lines solves the readability issue perfectly with
long expressions. Although if one is chasing some kind of
optimisations... I don't know, I see very often people want to
On 30 January 2017 at 21:25, David Mertz wrote:
> On Mon, Jan 30, 2017 at 11:52 AM, Mikhail V wrote:
>
>> *Theoretically* I see a solution by 'inlined' statements.
>> Take a long example:
>>
>> print ( merge (a, b, merge ( long_variable2,
On Mon, Jan 30, 2017 at 11:52 AM, Mikhail V wrote:
> *Theoretically* I see a solution by 'inlined' statements.
> Take a long example:
>
> print ( merge (a, b, merge ( long_variable2, long_variable2 ) )
>
> Now just split it in 2 lines:
>
> tmp <> merge (
tl;dr: I agree with you, Steven, as proven by my former post, augmented
with the details of your reply: there's no advantage to add a new
operator and language construct for this use case.—
On Sun, Jan 29, 2017 at 01:30:13PM +1100, Steven D'Aprano wrote:
> On Sat, Jan 28, 2017 at 03:16:27PM
On Sat, Jan 28, 2017 at 03:16:27PM +0100, zmo via Python-ideas wrote:
> Hi list o/
>
> This idea sounds fun, so as a thought experiment why not imagine one
> way of integrating it in what I believe would be pythonic enough.
This idea is sometimes called "the Collection Pipeline" design pattern,
On Sat, 28 Jan 2017 at 14:27 zmo via Python-ideas
wrote:
> I agree this would look a bit more elegant. To focus on the feature of
> that operator, instead of how to write it, I'll use XYZ instead of <| in
> this post.
My thoughts exactly :)
> So, considering it's
Hi list o/
This idea sounds fun, so as a thought experiment why not imagine one
way of integrating it in what I believe would be pythonic enough.
On Sat, Jan 28, 2017 at 12:41:24PM +, Ed Kellett wrote:
> FWIW, I'd spell it without the (), so it's simply a right-associative
> binary operator
On Sat, Jan 28, 2017 at 11:41 PM, Ed Kellett wrote:
> FWIW, I'd spell it without the (), so it's simply a right-associative binary
> operator on expressions, (a -> b, a) -> b, rather than magic syntax.
>
> print XYZ some_func XYZ another_func("Hello")
I'm not entirely sure
On Fri, 27 Jan 2017 at 21:29 Ethan Furman wrote:
On 01/27/2017 01:07 PM, Brent Brinkley wrote:
> Suggested structure:
>
> print() <| some_func() <| another_func("Hello")
My first question is what does this look like when print() and some_func()
have other parameters? In
On Fri, Jan 27, 2017 at 3:28 PM, Ethan Furman wrote:
> On 01/27/2017 01:07 PM, Brent Brinkley wrote:
>
>> Suggested structure:
>>
>> print() <| some_func() <| another_func("Hello")
>>
>
> My first question is what does this look like when print() and some_func()
> have
On 01/27/2017 01:07 PM, Brent Brinkley wrote:
I’m relatively new to the world of python
Welcome!
but in my short time here I’ve
fallen in love with how readable this language is. One issue that I’ve
seen in a lot of languages struggle with is nested function calls.
Parenthesis when
Hi,
This would break apart as soon as one of left functions takes more than one
parameter.
Best regards,
João Santos
On Fri, 27 Jan 2017, 22:08 Brent Brinkley, wrote:
> HI Everyone,
>
> I’m relatively new to the world of python but in my short time here I’ve
> fallen
HI Everyone,
I’m relatively new to the world of python but in my short time here I’ve fallen
in love with how readable this language is. One issue that I’ve seen in a lot
of languages struggle with is nested function calls. Parenthesis when nested
inherently create readability issues. I
13 matches
Mail list logo