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


Groups > comp.lang.python > #53466

Re: semicolon at end of python's statements

Path csiph.com!usenet.pasdenom.info!aioe.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Return-Path <antoon.pardon@rece.vub.ac.be>
X-Original-To python-list@python.org
Delivered-To python-list@mail.python.org
X-Spam-Status OK 0.004
X-Spam-Evidence '*H*': 0.99; '*S*': 0.00; 'else:': 0.03; 'syntax': 0.04; 'elif': 0.05; 'received:134': 0.05; 'say,': 0.05; 'level,': 0.07; 'clause': 0.09; 'if,': 0.09; 'repeated': 0.09; 'second.': 0.09; 'spaces': 0.09; 'worse': 0.09; 'python': 0.11; 'attached,': 0.16; 'block.': 0.16; 'clause,': 0.16; 'clause.': 0.16; 'clauses': 0.16; 'clauses.': 0.16; 'comp': 0.16; 'filter:': 0.16; 'for"': 0.16; 'for,': 0.16; 'illustrates': 0.16; 'indent': 0.16; 'iterator': 0.16; 'nesting': 0.16; 'objections': 0.16; 'option:': 0.16; 'prohibit': 0.16; 'readability': 0.16; 'uncommon': 0.16; 'version?': 0.16; 'subject:python': 0.16; 'prevent': 0.16; 'wrote:': 0.18; 'written': 0.21; 'seems': 0.21; '>>>': 0.22; 'separate': 0.22; 'header:User-Agent:1': 0.23; 'filtering': 0.24; "shouldn't": 0.24; 'together.': 0.24; "haven't": 0.24; 'this:': 0.26; 'header:In-Reply-To:1': 0.27; 'point': 0.28; 'raise': 0.29; "doesn't": 0.30; 'have,': 0.30; 'statement': 0.30; 'contrast,': 0.31; "d'aprano": 0.31; 'fine,': 0.31; 'indentation': 0.31; 'option.': 0.31; 'sep': 0.31; 'steven': 0.31; 'subject:end': 0.31; 'class': 0.32; 'option': 0.32; 'level.': 0.33; 'could': 0.34; 'problem': 0.35; 'agree': 0.35; 'except': 0.35; 'something': 0.35; 'done.': 0.35; 'but': 0.35; 'version': 0.36; 'really': 0.36; '+0200,': 0.36; 'combination': 0.36; 'controls': 0.36; 'sequence': 0.36; 'method': 0.36; "i'll": 0.36; 'should': 0.36; 'error.': 0.37; 'list': 0.37; 'level': 0.37; 'being': 0.38; 'filter': 0.38; 'saves': 0.38; 'whatever': 0.38; 'to:addr:python-list': 0.38; 'fact': 0.38; 'short': 0.38; 'anything': 0.39; 'bad': 0.39; 'to:addr:python.org': 0.39; 'enough': 0.39; 'either': 0.39; 'how': 0.40; 'chain': 0.60; 'consists': 0.60; 'numbers': 0.61; 'first': 0.61; "you've": 0.63; 'real': 0.63; 'more': 0.64; 'situation': 0.65; 'talking': 0.65; 'between': 0.67; 'believe': 0.68; 'benefit': 0.68; 'caused': 0.69; 'legal': 0.71; 'risk': 0.72; 'obvious': 0.74; 'potentially': 0.81; '"one': 0.84; 'cost,': 0.84; 'fourth': 0.84; 'gains': 0.84; 'nonsense.': 0.84; 'pardon': 0.84; 'absolutely': 0.87; 'dozen': 0.91; 'mistake': 0.91; 'write:': 0.91; 'hand,': 0.93; '2013': 0.98
X-IronPort-Anti-Spam-Filtered true
X-IronPort-Anti-Spam-Result Ap8EALVdJFKGuA9G/2dsb2JhbABawX+DAoE4gxgBAQQBbAwGCwsYCRYPCQMCAQIBRRMIAod4BrAziG+QBoQdA5d1hhiLToMi
Date Mon, 02 Sep 2013 11:45:19 +0200
From Antoon Pardon <antoon.pardon@rece.vub.ac.be>
User-Agent Mozilla/5.0 (X11; Linux i686; rv:10.0.12) Gecko/20130116 Icedove/10.0.12
MIME-Version 1.0
To python-list@python.org
Subject Re: semicolon at end of python's statements
References <1377735506.18906.15.camel@debian> <mailman.347.1377760274.19984.python-list@python.org> <1FETt.52607$Mw4.14965@fx15.am4> <CAPTjJmpBbf=BkZdeg3VdBYFvB0ADtyseGAMB214jJDyqZa=pmQ@mail.gmail.com> <CAA=1kxR_pT=MsUSSk0v-oij-0hSh0LEYrrP5i+5MukmcYfOGWA@mail.gmail.com> <7wob8gywds.fsf@benfinney.id.au> <mailman.385.1377858745.19984.python-list@python.org> <52213435$0$6599$c3e8da3$5496439d@news.astraweb.com> <mailman.458.1378068912.19984.python-list@python.org> <522446ae$0$2743$c3e8da3$76491128@news.astraweb.com>
In-Reply-To <522446ae$0$2743$c3e8da3$76491128@news.astraweb.com>
Content-Type text/plain; charset=ISO-8859-1
Content-Transfer-Encoding 7bit
X-BeenThere python-list@python.org
X-Mailman-Version 2.1.15
Precedence list
List-Id General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe <http://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive <http://mail.python.org/pipermail/python-list/>
List-Post <mailto:python-list@python.org>
List-Help <mailto:python-list-request@python.org?subject=help>
List-Subscribe <http://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Newsgroups comp.lang.python
Message-ID <mailman.476.1378115131.19984.python-list@python.org> (permalink)
Lines 147
NNTP-Posting-Host 2001:888:2000:d::a6
X-Trace 1378115131 news.xs4all.nl 15930 [2001:888:2000:d::a6]:49327
X-Complaints-To abuse@xs4all.nl
Xref csiph.com comp.lang.python:53466

Show key headers only | View raw


Op 02-09-13 10:05, Steven D'Aprano schreef:
> On Sun, 01 Sep 2013 21:58:15 +0200, Antoon Pardon wrote:
> 
>> Op 31-08-13 02:09, Steven D'Aprano schreef:
> 
>>> Adding a fourth option:
>>>
>>> for spam in sequence if predicate(spam):
>>>      process(spam)
>>>
>>> saves absolutely nothing except a line and an indent level, neither of
>>> which are in short supply, and gains nothing in readability over Option
>>> 1.
>>
>> So what is the big difference between this situation and the following:
>>
>> | else:
>> |     if condition:
>> |         whatever
>>
>> which in python we can write:
>>
>> | elif condition:
>> |     whatever
>>
>>
>> So either is seems this was a design mistake or a line and an indent
>> level can be important enough to allow a combination of controls.
> 
> 
> The difference is that elif is syntax for chaining potentially large 
> numbers of else if clauses:
> 
> if a:
> else:
>     if b:
>     else:
>         if c:
>         else:
>             if d:
>             else:
> 
> It's not uncommon to have, say, a dozen separate elif clauses. Put that 
> inside a method inside a class and you've got an indent of 56 spaces 
> inside the final else block. But that's not really the problem, the real 
> problem is that repeated nesting like this obscures the fact that it is a 
> chain of if...if...if...if and all the if's really should be at the same 
> indentation level.



> In contrast, you never need to write something like this:
> 
> for item in seq: if a: if b: if c: if d: ...
> 
> since that's better written as 
> 
> for item in seq: if a and b and c and d:
> 
> So a "filtered for" only includes a single if clause. Multiple if clauses 
> don't match the "one line or two" scenario:
> 
> for item in seq: if cond: <block> elif predicate: <block> else: <block>
> 
> is not an option. With a single if, filtering the for loop, this is an 
> option:
> 
> # with or without the first colon
> for item in seq: if cond:  
>     <block>
> 
> versus:
> 
> for item in seq:
>     if cond:
>         <block>
> 
> What's the benefit of the first version? It doesn't make it any more 
> obvious that the for is being filtered.

It makes that just as obvious as using an elif makes it obvious we are
having a chain of ifs. It is not obvious because it can be logically
deduced, but is is obvious by how programmic idioms start occuring.

Just as people sometime prefer

| else:
|    if ...

If they think that illustrates the decision process more clearly people
could chose whether to use the combined or seperated controls depending
on whether they considered the if as the filter part of an iterator or
as an independ decision proces.

> It doesn't keep a whole chain of 
> if clauses together. It doesn't let you do anything that you haven't 
> already done. It just saves an indent and a newline. The cost, on the 
> other hand, includes the risk that people will try to do this:
> 
> for item in seq: if cond:
>     do_this()
>     do_that()
>     else:
>         do_something else()
> 
> which is clearly nonsense. Worse is this:
> 
> for item in seq: if cond:
>     do_this()
>     do_that()
> else:
>     do_something else()
> 
> which is still nonsense but won't raise SyntaxError.

Why shouldn't this raise a SyntaxError?

> It would be a Bad Thing if adding a legal else clause to a legal if 
> clause caused a syntax error.

But we are not necessarily talking about an if clause, we can be talking
about an iterator with a filter attached, or about a combined control.

> But the only way to prevent that is to 
> prohibit the for...if one line version in the first place.

No it isn't.

> *None* of these objections apply to the list comp version of for, where 
> the "block" consists of a single statement before the "for". So despite a 
> superficial (very superficial) similarity between
> 
> [expr for item in seq if filter]
> 
> and 
> 
> for item in seq if filter:
>     expr
> 
> I believe that Python is right to allow the first and prohibit the second.

Fine, at this point I'll think we'll just have to agree to disagree.

-- 
Antoon Pardon

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: semicolon at end of python's statements "Sam Fourman Jr." <sfourman@gmail.com> - 2013-08-28 22:10 -0400
  Re: semicolon at end of python's statements Alister <alister.ware@ntlworld.com> - 2013-08-29 09:39 +0000
    Re: semicolon at end of python's statements Chris Angelico <rosuav@gmail.com> - 2013-08-29 19:52 +1000
    Re: semicolon at end of python's statements Fábio Santos <fabiosantosart@gmail.com> - 2013-08-29 11:02 +0100
    Re: semicolon at end of python's statements Ben Finney <ben+python@benfinney.id.au> - 2013-08-30 08:17 +1000
    Re: semicolon at end of python's statements Chris Angelico <rosuav@gmail.com> - 2013-08-30 08:50 +1000
    Re: semicolon at end of python's statements Ben Finney <ben+python@benfinney.id.au> - 2013-08-30 14:55 +1000
    Re: semicolon at end of python's statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-08-30 09:15 +0200
    Re: semicolon at end of python's statements Chris Angelico <rosuav@gmail.com> - 2013-08-30 17:25 +1000
    Re: semicolon at end of python's statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-08-30 09:48 +0200
    Re: semicolon at end of python's statements Fábio Santos <fabiosantosart@gmail.com> - 2013-08-30 11:32 +0100
      Re: semicolon at end of python's statements Roy Smith <roy@panix.com> - 2013-08-30 06:53 -0400
        Re: semicolon at end of python's statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-08-30 16:14 +0200
        Re: semicolon at end of python's statements Chris Angelico <rosuav@gmail.com> - 2013-08-31 08:18 +1000
      Re: semicolon at end of python's statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-08-31 00:09 +0000
        Re: semicolon at end of python's statements Terry Reedy <tjreedy@udel.edu> - 2013-08-31 01:03 -0400
        Re: semicolon at end of python's statements Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-08-31 10:47 +0300
          Re: semicolon at end of python's statements Paul Rudin <paul.nospam@rudin.co.uk> - 2013-08-31 09:00 +0100
            Re: semicolon at end of python's statements Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-08-31 13:28 +0300
            Re: semicolon at end of python's statements Grant Edwards <invalid@invalid.invalid> - 2013-09-02 14:20 +0000
              Re: semicolon at end of python's statements Tim Chase <python.list@tim.thechases.com> - 2013-09-02 09:45 -0500
                Re: semicolon at end of python's statements Roy Smith <roy@panix.com> - 2013-09-02 10:47 -0400
                Re: semicolon at end of python's statements Tim Chase <python.list@tim.thechases.com> - 2013-09-02 12:58 -0500
                Re: semicolon at end of python's statements Chris Angelico <rosuav@gmail.com> - 2013-09-03 07:07 +1000
        Re: semicolon at end of python's statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-09-01 19:58 +0200
        Re: semicolon at end of python's statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-09-01 21:58 +0200
          Re: semicolon at end of python's statements Steven D'Aprano <steve@pearwood.info> - 2013-09-02 08:05 +0000
            Re: semicolon at end of python's statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-09-02 11:45 +0200
            Re: semicolon at end of python's statements Fábio Santos <fabiosantosart@gmail.com> - 2013-09-02 11:42 +0100
            Re: semicolon at end of python's statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-09-02 12:58 +0200
            Re: semicolon at end of python's statements "albert visser" <albert.visser@gmail.com> - 2013-09-02 19:44 +0200
              Re: semicolon at end of python's statements Roy Smith <roy@panix.com> - 2013-09-02 13:53 -0400
                Re: semicolon at end of python's statements Neil Cerutti <neilc@norwich.edu> - 2013-09-03 17:15 +0000
                Re: semicolon at end of python's statements Neil Cerutti <neilc@norwich.edu> - 2013-09-03 20:00 +0000
            Re: semicolon at end of python's statements Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-09-02 17:24 -0400
        Re: semicolon at end of python's statements MRAB <python@mrabarnett.plus.com> - 2013-09-02 00:30 +0100
        Re: semicolon at end of python's statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-09-02 10:29 +0200
          Re: semicolon at end of python's statements Steven D'Aprano <steve@pearwood.info> - 2013-09-02 09:52 +0000
            Re: semicolon at end of python's statements Chris Angelico <rosuav@gmail.com> - 2013-09-02 20:14 +1000
              Re: semicolon at end of python's statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-02 14:57 +0000
            Re: semicolon at end of python's statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-09-02 12:52 +0200
            Re: semicolon at end of python's statements Modulok <modulok@gmail.com> - 2013-09-02 17:17 -0600
              Re: semicolon at end of python's statements Roy Smith <roy@panix.com> - 2013-09-02 19:54 -0400
                Re: semicolon at end of python's statements Modulok <modulok@gmail.com> - 2013-09-02 18:56 -0600

csiph-web