Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #63220 > unrolled thread

Postfix conditionals

Back to article view | Back to comp.lang.python

Contents

  Postfix conditionals Göktuğ Kayaalp <self@gkayaalp.com> - 2014-01-05 22:24 +0200
    Re: Postfix conditionals Roy Smith <roy@panix.com> - 2014-01-05 15:41 -0500
      Re: Postfix conditionals Göktuğ Kayaalp <self@gkayaalp.com> - 2014-01-05 22:54 +0200
      Re: Postfix conditionals Dan Stromberg <drsalists@gmail.com> - 2014-01-05 13:08 -0800
    Re: Postfix conditionals "Rhodri James" <rhodri@wildebst.org.uk> - 2014-01-06 01:40 +0000
      Re: Postfix conditionals Göktuğ Kayaalp <self@gkayaalp.com> - 2014-01-06 09:51 +0200
        Re: Postfix conditionals "Rhodri James" <rhodri@wildebst.org.uk> - 2014-01-07 00:48 +0000
    Re: Postfix conditionals "BartC" <bc@freeuk.com> - 2014-02-03 23:43 +0000
      Re: Postfix conditionals Göktuğ Kayaalp <self@gkayaalp.com> - 2014-02-04 07:16 +0200
        Re: Postfix conditionals "BartC" <bc@freeuk.com> - 2014-02-04 10:00 +0000
      Re: Postfix conditionals Chris Angelico <rosuav@gmail.com> - 2014-02-04 16:23 +1100

#63220 — Postfix conditionals

Hi,

AFAIK, we do not have "postfix conditionals" in Python, i.e. a condition 
appended to a
statement, which determines whether the statement runs or not:

   py> for i in [False]:
   ...     break if not i

The above piece of code is equivalent to this in Python:

   py> for i in [False]:
   ...    if not i
   ...        break

I believe that the first example is superior to the second example when 
the two is compared
for readability and intuitiveness.  We already have a ternary statement 
that looks similar,

   py> print('hi') if True else None

so I reckon there would be no breakage in old code if this kind of 
syntax was added.  Ruby has
this, and AFAIK Perl also does.

I lack the knowledge of whether the community has opinions on this kind 
of notation, so I am
posting this here instead of the ideas list.  What are your thoughts on 
this?

         gk

[toc] | [next] | [standalone]

#63221

In article <mailman.4966.1388953508.18130.python-list@python.org>,
 Göktu€ Kayaalp <self@gkayaalp.com> wrote:

>    py> for i in [False]:
>    ...     break if not i

Python is not Perl.

[toc] | [prev] | [next] | [standalone]

#63222

On 05-01-2014 22:41, Roy Smith wrote:
> In article <mailman.4966.1388953508.18130.python-list@python.org>,
>   Göktu€ Kayaalp <self@gkayaalp.com> wrote:
>
>>     py> for i in [False]:
>>     ...     break if not i
> Python is not Perl.
Well done!  Good for you, that you know the fact; but you are not being 
constructive.

Python is not C either, but we have the while loop.  Python is not 
Smalltalk, but we have
classes.  Python is not LISP, but we have function literals.

Hopefully Guido did not have your approach back when he created Python, 
or we'd have an
assembly language or something instead today.

[toc] | [prev] | [next] | [standalone]

#63224

On Sun, Jan 5, 2014 at 12:41 PM, Roy Smith <roy@panix.com> wrote:
> In article <mailman.4966.1388953508.18130.python-list@python.org>,
>  Göktu€ Kayaalp <self@gkayaalp.com> wrote:
>
>>    py> for i in [False]:
>>    ...     break if not i
>
> Python is not Perl.

Personally, I find the suggested syntax jarring.  I'd prefer that it
not go into Python.

[toc] | [prev] | [next] | [standalone]

#63254

On Sun, 05 Jan 2014 20:24:53 -0000, Göktuğ Kayaalp <self@gkayaalp.com>  
wrote:

> AFAIK, we do not have "postfix conditionals" in Python, i.e. a condition  
> appended to a statement, which determines whether the statement runs or  
> not:

>    py> for i in [False]:
>    ...     break if not i

>  The above piece of code is equivalent to this in Python:

>    py> for i in [False]:
>    ...    if not i
>    ...        break

> I believe that the first example is superior to the second example when  
> the two is compared for readability and intuitiveness.

In my past life as a newcomer to Perl, I thought this too.  Postfix  
conditionals read more like English, so they would be easier to take in  
and understand.  As I wrote more code, I discovered that this didn't seem  
to be the case; except in very simple cases, I had to mentally transpose  
the conditional back to the start of the statement to properly comprehend  
what was going on and what the results would be for my sample data.

It looks like a good idea, but I don't think it works that well in  
practice.

-- 
Rhodri James *-* Wildebeest Herder to the Masses

[toc] | [prev] | [next] | [standalone]

#63274

On 06-01-2014 03:40, Rhodri James wrote:
> On Sun, 05 Jan 2014 20:24:53 -0000, Göktuğ Kayaalp <self@gkayaalp.com> 
> wrote:
>
>> AFAIK, we do not have "postfix conditionals" in Python, i.e. a 
>> condition appended to a statement, which determines whether the 
>> statement runs or not:
>
>>    py> for i in [False]:
>>    ...     break if not i
>
>>  The above piece of code is equivalent to this in Python:
>
>>    py> for i in [False]:
>>    ...    if not i
>>    ...        break
>
>> I believe that the first example is superior to the second example 
>> when the two is compared for readability and intuitiveness.
>
> In my past life as a newcomer to Perl, I thought this too. Postfix 
> conditionals read more like English, so they would be easier to take 
> in and understand.  As I wrote more code, I discovered that this 
> didn't seem to be the case; except in very simple cases, I had to 
> mentally transpose the conditional back to the start of the statement 
> to properly comprehend what was going on and what the results would be 
> for my sample data.
>
> It looks like a good idea, but I don't think it works that well in 
> practice.
>
Thanks for the input! I'd be quite interested in examples which required 
you to "mentally transpose the conditional back to the start of the 
statement", by the way.

         gk

[toc] | [prev] | [next] | [standalone]

#63387

On Mon, 06 Jan 2014 07:51:28 -0000, Göktuğ Kayaalp <self@gkayaalp.com>  
wrote:

> Thanks for the input! I'd be quite interested in examples which required  
> you to "mentally transpose the conditional back to the start of the  
> statement", by the way.

Sorry, it's been too long and I don't have any relevant Perl around any  
more.  I think it had to do with losing the visual cue of indentation, and  
just having to think that little bit harder to notice that I wasn't  
dealing with purely linear code.

-- 
Rhodri James *-* Wildebeest Herder to the Masses

[toc] | [prev] | [next] | [standalone]

#65390

"Göktuğ Kayaalp" <self@gkayaalp.com> wrote in message
news:mailman.4966.1388953508.18130.python-list@python.org...

> AFAIK, we do not have "postfix conditionals" in Python, i.e. a condition
> appended to a
> statement, which determines whether the statement runs or not:
>
>   py> for i in [False]:
>   ...     break if not i
>
> The above piece of code is equivalent to this in Python:
>
>   py> for i in [False]:
>   ...    if not i
>   ...        break

> What are your thoughts on this?

I develop my own language (not Python, but also dynamic and interpreted).

I have this feature, and it's OK, but not indispensible.  I varied it a bit
by allowing 'if', 'when' and 'unless' as the conditionals, just to break it
up a little. However, it just maps internally to a regular if-statement.

In Python though, the normal way of writing 'break if not i' is about the
same length (in my language it's somewhat longer), so I can't see it getting
much support.

What would be far more useful would be a proper 'switch' statement, but if
that's not in, then I don't think your proposal will get far!

(There are various clunky workarounds for switch - one idea is to use an
if-elseif chain, but that's just what it tries to avoid. Switch is 
attractive for an interpreted language because - provided all cases are 
constants, a bit of a problem in Python, because as soon as you give a name 
to something, it's no longer constant - it can be implemented very 
efficiently.)

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#65404

[comments inline]

"BartC" <bc@freeuk.com> writes:

> "Göktuğ Kayaalp" <self@gkayaalp.com> wrote in message
> news:mailman.4966.1388953508.18130.python-list@python.org...
>
>> AFAIK, we do not have "postfix conditionals" in Python, i.e. a condition
>> appended to a
>> statement, which determines whether the statement runs or not:
>>
>>   py> for i in [False]:
>>   ...     break if not i
>>
>> The above piece of code is equivalent to this in Python:
>>
>>   py> for i in [False]:
>>   ...    if not i
>>   ...        break
>
>> What are your thoughts on this?
>
> I develop my own language (not Python, but also dynamic and interpreted).

Would love to see that, if possible!

> I have this feature, and it's OK, but not indispensible.  I varied it a bit
> by allowing 'if', 'when' and 'unless' as the conditionals, just to break it
> up a little. However, it just maps internally to a regular if-statement.
>
> In Python though, the normal way of writing 'break if not i' is about the
> same length (in my language it's somewhat longer), so I can't see it getting
> much support.

I do not really think that string length is not of much significance.
The actual fact that disallows my proposal from being favoured/implemented
is that in Python, `break', `return' and `continue' are statements and the
community encourages having one statement per line, so that the source code
is easily understandable.  With my proposal implemented, the language would
would be encouraging having multiple statements in one line, that looks
like a single statement, but is indeed a composition of two.

I rather dislike the statement-orientedness of Python, but still, it is
a good device of easening for the language developers and beginners when
the fact that we use indentation to denote blocks is considered.

> What would be far more useful would be a proper 'switch' statement, but if
> that's not in, then I don't think your proposal will get far!
>
> (There are various clunky workarounds for switch - one idea is to use an
> if-elseif chain, but that's just what it tries to avoid. Switch is
> attractive for an interpreted language because - provided all cases
> are constants, a bit of a problem in Python, because as soon as you
> give a name to something, it's no longer constant - it can be
> implemented very efficiently.)
>
> -- 
> Bartc 

[toc] | [prev] | [next] | [standalone]

#65414

"GöktuğKayaalp" <self@gkayaalp.com> wrote in message
news:mailman.6377.1391490975.18130.python-list@python.org...
> "BartC" <bc@freeuk.com> writes:
>
>> "Göktuğ Kayaalp" <self@gkayaalp.com> wrote in message
>> news:mailman.4966.1388953508.18130.python-list@python.org...
>>
>>> AFAIK, we do not have "postfix conditionals" in Python, i.e. a condition
>>> appended to a
>>> statement, which determines whether the statement runs or not:
>>>
>>>   py> for i in [False]:
>>>   ...     break if not i

>>> What are your thoughts on this?
>>
>> I develop my own language (not Python, but also dynamic and interpreted).

(First, some apologies; I thought the OP was dated February not January!)

> Would love to see that, if possible!

(If you're into Python, then I doubt it because I don't have classes or any
of those other Pythonic things that people like. However my language is a
lot less dynamic and therefore can be much faster. I have a few interesting
variations on statements as well; syntax is cheap and I don't know why many
languages, Python included, have such a paucity of control and selection
statements.

I also have a project that translates my syntax into Python; the intention
there was to be able to make use of some of its libraries because I don't
have many of my own!)

>> I have this feature, and it's OK, but not indispensible.  I varied it a
>> bit
>> by allowing 'if', 'when' and 'unless' as the conditionals, just to break
>> it
>> up a little. However, it just maps internally to a regular if-statement.
>>
>> In Python though, the normal way of writing 'break if not i' is about the
>> same length (in my language it's somewhat longer), so I can't see it
>> getting
>> much support.
>
> I do not really think that string length is not of much significance.
> The actual fact that disallows my proposal from being favoured/implemented
> is that in Python, `break', `return' and `continue' are statements and the
> community encourages having one statement per line, so that the source
> code
> is easily understandable.  With my proposal implemented, the language
> would
> would be encouraging having multiple statements in one line, that looks
> like a single statement, but is indeed a composition of two.

But, Python already allows you to combine two statements on a line, as in:

 if a: s
 while b: t

So your:

 s if a

is little different (although s will need to be restricted; 'if b if a' will
look a bit odd). And someone mentioned the ternary expression which looks
similar to your proposal.

I suppose you can also argue that the if-part is not a statement at all,
just an expression that is part of the statement (you'd have to redefine
break and other statements to have an optional condition). If written as:

 break(not i)

then it certainly won't look like two statements! Your proposal has the 
advantage in that it gives more dominance to the statement, making the code 
somewhat clearer, comparing with burying it inside an if-statement.

> I rather dislike the statement-orientedness of Python, but still, it is
> a good device of easening for the language developers and beginners when
> the fact that we use indentation to denote blocks is considered.

(I used to have a syntax where statements and expressions were
interchangeable. Now I have them distinct, which makes many things much
easier, it picks up more errors (and makes it simpler to translate to
translate into languages which aren't quite as expressive!))

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#65406

On Tue, Feb 4, 2014 at 4:16 PM, Göktuğ Kayaalp <self@gkayaalp.com> wrote:
> With my proposal implemented, the language would
> would be encouraging having multiple statements in one line, that looks
> like a single statement, but is indeed a composition of two.

I wouldn't have a problem with

if not i: break

in Python, as long as the condition is short. In something that reads
from a socket until the other end closes, for instance, I'm fine with
this:

while True:
    data = sock.read(1024)
    if not data: break
    do_stuff_with(data)

which will stop as soon as sock.read() returns "", which it does when
the other end is gone. (I wrote something doing exactly this today,
and did exactly this. Probably could have made the code a bit simpler
if I could depend on Python 3.3, but it has to run on 2.7 and maybe
2.6 so I had to stick with their facilities.)

Yes, it's two statements, but a list comprehension is a whole pile of
statement-y things, and that's usually a single line. If it's doing
one conceptual action, it's okay to not split it.

ChrisA

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web