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

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

Re: semicolon at end of python's statements

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#53487

On 2013-09-02 14:20, Grant Edwards wrote:
> >> This saves an indent level.
> >
> > Just out of interest: is saving an indent level a useful thing?
> 
> Perhaps he's worried about the world running out of tabs?
> 
> I heard that most of the tab mines are in China and they're going to
> stop exporting...

And buying all that indentation supports terrorists.  Conserve
whitespace or the terrorists win! :-)

-tkc

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

#53489

In article <mailman.491.1378133042.19984.python-list@python.org>,
 Tim Chase <python.list@tim.thechases.com> wrote:

> On 2013-09-02 14:20, Grant Edwards wrote:
> > >> This saves an indent level.
> > >
> > > Just out of interest: is saving an indent level a useful thing?
> > 
> > Perhaps he's worried about the world running out of tabs?
> > 
> > I heard that most of the tab mines are in China and they're going to
> > stop exporting...
> 
> And buying all that indentation supports terrorists.  Conserve
> whitespace or the terrorists win! :-)

What really gets me is the stupid TSA.  You're allowed to bring as many 
spaces as you want on an airplane, but they confiscate all your tabs as 
the security checkpoint.

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

#53519

On 2013-09-02 10:47, Roy Smith wrote:
> > > Perhaps he's worried about the world running out of tabs?
> > > 
> > > I heard that most of the tab mines are in China and they're
> > > going to stop exporting...
> > 
> > And buying all that indentation supports terrorists.  Conserve
> > whitespace or the terrorists win! :-)
> 
> What really gets me is the stupid TSA.  You're allowed to bring as
> many spaces as you want on an airplane, but they confiscate all
> your tabs as the security checkpoint.

Well, they *are* the "Tab Safety Administration".  ;-)

-tkc

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

#53527

On Tue, Sep 3, 2013 at 3:58 AM, Tim Chase <python.list@tim.thechases.com> wrote:
> On 2013-09-02 10:47, Roy Smith wrote:
>> > > Perhaps he's worried about the world running out of tabs?
>> > >
>> > > I heard that most of the tab mines are in China and they're
>> > > going to stop exporting...
>> >
>> > And buying all that indentation supports terrorists.  Conserve
>> > whitespace or the terrorists win! :-)
>>
>> What really gets me is the stupid TSA.  You're allowed to bring as
>> many spaces as you want on an airplane, but they confiscate all
>> your tabs as the security checkpoint.
>
> Well, they *are* the "Tab Safety Administration".  ;-)

Plus, they need to keep on confiscating them. It's all part of the
surveillance schemes the government's doing - trying to keep tabs on
everyone.

ChrisA

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

#53421

Op 31-08-13 02:09, Steven D'Aprano schreef:
> On Fri, 30 Aug 2013 11:32:17 +0100, Fábio Santos wrote:
>
>> On 29 Aug 2013 23:20, "Ben Finney" <ben+python@benfinney.id.au> wrote:
>>>
>>> Fábio Santos <fabiosantosart@gmail.com> writes:
>>>
>>>> It is a shame that this is not possible in python. for..if exists in
>>>> comprehensions and not in regular loops but that would be nice
>>>> sometimes.
>>>
>>> So you use it in a generator expression, and iterate over the
>>> generator:
>>>
>>>      for foo in (spam for spam in sequence if predicate(spam)):
>>>          process(spam)
>>>
>>> That way, there's no need for new syntax.
>>
>> The problem I have with that strategy is that it is repetitive and
>> hinders readability. You wrote "for" and "in" twice, and spam (a pretty
>> useless intermediate variable) thrice!
>
> There is no need for spam to be "intermediate", and the fact that it
> shouldn't be is demonstrated by Ben's error in referring to "process
> (spam)" instead of "process(foo)".
>
> We really are spoiled for choice here. We can write any of these:
>
> # Option 1
> for spam in sequence:
>      if predicate(spam):
>          process(spam)
>
> # Option 2
> for spam in filter(predicate, sequence):
>      process(spam)
>
> # Option 3
> for spam in (spam for spam in sequence if predicate(spam)):
>      process(spam)
>
>
> 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.

I find this rather disenginuous. Dare to suggest here that python might
benetif by incluidng end markers for its suits because it would make it 
clearer how many indent levels were done, and chances are someone here
will suggest that too many indent levels are a sign of bad coding
practice, but when someone suggests a change that would allow him
to structure his program more like how he sees it and indent levels
are not short in supply, suggesting there is no problem, no matter how
many one uses.

-- 
Antoon Pardon

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

#53432

Op 31-08-13 02:09, Steven D'Aprano schreef:
> On Fri, 30 Aug 2013 11:32:17 +0100, Fábio Santos wrote:
>

>
> We really are spoiled for choice here. We can write any of these:
>
> # Option 1
> for spam in sequence:
>      if predicate(spam):
>          process(spam)
>

>
> 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.

-- 
Antoon Pardon

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

#53460

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 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.

It would be a Bad Thing if adding a legal else clause to a legal if 
clause caused a syntax error. But the only way to prevent that is to 
prohibit the for...if one line version in the first place.

*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.



-- 
Steven

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

#53466

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

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

#53471

On 09/02/2013 10:45 AM, Antoon Pardon wrote:
> Op 02-09-13 10:05, Steven D'Aprano schreef:
>> 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?
>
Because it would be parsed as a valid for .. else construct. Either that 
or become ambiguous to the programmer, who would not be sure whether he 
was writing an else clause for the `if`, or for the `for`.

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

#53473

Op 02-09-13 12:42, Fábio Santos schreef:
> On 09/02/2013 10:45 AM, Antoon Pardon wrote:
>> Op 02-09-13 10:05, Steven D'Aprano schreef:
>>> 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?
>>
> Because it would be parsed as a valid for .. else construct. Either that
> or become ambiguous to the programmer, who would not be sure whether he
> was writing an else clause for the `if`, or for the `for`.

I didn't thought about that, but in that case why should we
automatically think of it as nonsense?

I also don't see how this would be that ambigous. The else
lines up with the for, so it seems rather obvious for which
he was writing an else clause.

-- 
Antoon Pardon

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

#53515

On Mon, 02 Sep 2013 12:58:23 +0200, Antoon Pardon  
<antoon.pardon@rece.vub.ac.be> wrote:

> Op 02-09-13 12:42, Fábio Santos schreef:
>> On 09/02/2013 10:45 AM, Antoon Pardon wrote:
>>> Op 02-09-13 10:05, Steven D'Aprano schreef:

[...]

>>>>
>>>> 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?
>>>
>> Because it would be parsed as a valid for .. else construct. Either that
>> or become ambiguous to the programmer, who would not be sure whether he
>> was writing an else clause for the `if`, or for the `for`.
>

[...]
>
> I also don't see how this would be that ambigous. The else
> lines up with the for, so it seems rather obvious for which
> he was writing an else clause.
>

My first association would be with the for, but someone could also be  
thinking it's referring to the if on the same line, because there wouldn't  
be any other way to write it (besides nesting the if).

I wouldn't like this syntax anyway, two colons and all.

When I first saw the idea of a nested for .. if construct the thing that  
came to mind was another nesting, namely that of context managers. While I  
don't mind using

     with <context-1>:
         with <context-2>:
             do_stuff

I like being able to do e.g.

     with open('some_file') as _in, open('another_file', 'w') as _out:

because it makes it obvious that the context managers are related.
Expressing that the for and the if are related also appeals to me.
Another parallel might be slicing, where you can specify not only a start  
and an end value, but also an interval (which could be seen as a kind of  
filtering condition).

I think that if you really want to show the "filtered for" as a somewhat  
different concept than a for that just happens to have an if in its suite,  
that should be made visible.
Coming back to my first association mentioned above, why not use a comma?

for <identifier> in <iterable>, <condition>:
     <stuff>

(come to think of it, it has the added bonus that you won't get ambiguity  
what an else might be about).


Somehow this makes sense to me. But then, I also like 'x = y if  
<condition> else z'.
Moreover, I'm Dutch (...)

Albert Visser
-- 
Using Opera's mail client: http://www.opera.com/mail/

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

#53518

In article <mailman.508.1378143885.19984.python-list@python.org>,
 "albert visser" <albert.visser@gmail.com> wrote:

> I like being able to do e.g.
> 
>      with open('some_file') as _in, open('another_file', 'w') as _out:

It would be nice if you could write that as:

      with open('some_file'), open('another_file, 'w') as _in, _out:

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

#53575

On 2013-09-02, Roy Smith <roy@panix.com> wrote:
> In article <mailman.508.1378143885.19984.python-list@python.org>,
>  "albert visser" <albert.visser@gmail.com> wrote:
>
>> I like being able to do e.g.
>> 
>>      with open('some_file') as _in, open('another_file', 'w') as _out:
>
> It would be nice if you could write that as:
>
>       with open('some_file'), open('another_file, 'w') as _in, _out:

3.2 and above provide contextlib.ExitStack, which I just now
learned about.

with contextlib.ExitStack() as stack:
    _in = stack.enter_context(open('some_file'))
    _out = stack.enter_context(open('another_file', 'w'))

It ain't beautiful, but it unfolds the nesting and gets rid of
the with statement's line-wrap problems.

-- 
Neil Cerutti

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

#53577

On 2013-09-03, Neil Cerutti <neilc@norwich.edu> wrote:
> 3.2 and above provide contextlib.ExitStack, which I just now
> learned about.
>
> with contextlib.ExitStack() as stack:
>     _in = stack.enter_context(open('some_file'))
>     _out = stack.enter_context(open('another_file', 'w'))
>
> It ain't beautiful, but it unfolds the nesting and gets rid of
> the with statement's line-wrap problems.

It just occurred to me that in most of my use cases ExitStack
saves me from coming up with a name for the file objects at all,
since they are needed only to make csv objects.

Here's a csv file transformer pattern:

import contextlib
import csv

import transform

with contextlib.ExitStack() as stack:
    reader = csv.DictReader(stack.enter_context(open('some_file', newline='')))
    writer = csv.DictWriter(
        stack.enter_context(open('another_file', 'w', newline='')),
        fieldnames=reader.fieldnames)
    writer.writeheader()
    for record in reader:
        writer.writerow(transform.transform(record))

Too bad it's so dense looking.

-- 
Neil Cerutti

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

#53529

On Mon, 02 Sep 2013 19:44:33 +0200, "albert visser"
<albert.visser@gmail.com> declaimed the following:


>Coming back to my first association mentioned above, why not use a comma?
>
>for <identifier> in <iterable>, <condition>:
>     <stuff>
>

	Because the comma turns that into a tuple consisting of your iterable
and your condition...

>>> for i in 1, 3, 5, 4:
... 	print i
... 	
1
3
5
4
>>> 

>>> x = 1
>>> i = 3
>>> for i in xrange(3), x<i:
... 	print i
... 	
xrange(3)
True
>>> 
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#53439

On 01/09/2013 20:58, Antoon Pardon wrote:
> Op 31-08-13 02:09, Steven D'Aprano schreef:
>> On Fri, 30 Aug 2013 11:32:17 +0100, Fábio Santos wrote:
>>
>
>>
>> We really are spoiled for choice here. We can write any of these:
>>
>> # Option 1
>> for spam in sequence:
>>      if predicate(spam):
>>          process(spam)
>>
>
>>
>> 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.
>
'elif' is for cascading ifs:

if ...:
    ...
elif ...:
    ...
elif ...:
    ...
elif ...:
    ...
else:
    ...

Without 'elif' you would be forced to write:

if ...:
    ...
else:
     if ...:
        ...
     else:
         if ...:
            ...
         else:
             if ...:
                ...
             else:
                ...

On the other hand, for...if is much less of a problem.

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

#53462

Op 02-09-13 01:30, MRAB schreef:
> On 01/09/2013 20:58, Antoon Pardon wrote:
>> Op 31-08-13 02:09, Steven D'Aprano schreef:
>>> On Fri, 30 Aug 2013 11:32:17 +0100, Fábio Santos wrote:
>>>
>>
>>>
>>> We really are spoiled for choice here. We can write any of these:
>>>
>>> # Option 1
>>> for spam in sequence:
>>>      if predicate(spam):
>>>          process(spam)
>>>
>>
>>>
>>> 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.
>>
> 'elif' is for cascading ifs:
> 
> if ...:
>    ...
> elif ...:
>    ...
> elif ...:
>    ...
> elif ...:
>    ...
> else:
>    ...
> 
> Without 'elif' you would be forced to write:
> 
> if ...:
>    ...
> else:
>     if ...:
>        ...
>     else:
>         if ...:
>            ...
>         else:
>             if ...:
>                ...
>             else:
>                ...
> 
> On the other hand, for...if is much less of a problem.

So what is the problem with being forced to write it like this? We have
just learned that there is no short supply of indent levels, so why
should this bother us?

The only reason this should bother us, is if we think that indent levels
are a somewhat limited commodity and/or the way we view the process
structure is better illustrated written the first way. But if we think
those arguments carry some weight, there is no reason to only consider
them in the case of an else if combination. Why should we be more
concerned with cascading ifs than with cascading controls in general?

Not that I expect this to change, but it illustrates why for a number
of people the forced indentation can be an annoyance. All these
discussions about combining controls would have been unnecessary
without the enforced strict indentation. In that case we wouldn't have
needed elif because we could have just written "else: if" or "else if"
we wouldn't now be discussing the pro and cons of loop comprehension
because we could have just layed out the code so that it illustrated
our intention of a loop comprehension.

-- 
Antoon Pardon

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

#53467

On Mon, 02 Sep 2013 10:29:05 +0200, Antoon Pardon wrote:

> Why should we be more
> concerned with cascading ifs than with cascading controls in general?

What cascading controls?

for element in seq:
    if filter:
        <block>


is not a cascading control.

[...] 
> All these discussions
> about combining controls would have been unnecessary without the
> enforced strict indentation. 

Instead, we would have spent 100 times as much time and energy debating 
the One True Indentation Scheme, akin to the brace wars that went on for 
*years* in the C community. And still haven't completely gone.


> we wouldn't now be
> discussing the pro and cons of loop comprehension because we could have
> just layed out the code so that it illustrated our intention of a loop
> comprehension.

Which the current syntax is perfectly fine at doing.



-- 
Steven

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

#53469

On Mon, Sep 2, 2013 at 7:52 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> Instead, we would have spent 100 times as much time and energy debating
> the One True Indentation Scheme, akin to the brace wars that went on for
> *years* in the C community. And still haven't completely gone.

You mean like debating tabs vs spaces in Python code?

ChrisA

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

#53490

On Mon, 02 Sep 2013 20:14:40 +1000, Chris Angelico wrote:

> On Mon, Sep 2, 2013 at 7:52 PM, Steven D'Aprano <steve@pearwood.info>
> wrote:
>> Instead, we would have spent 100 times as much time and energy debating
>> the One True Indentation Scheme, akin to the brace wars that went on
>> for *years* in the C community. And still haven't completely gone.
> 
> You mean like debating tabs vs spaces in Python code?

Yes, only worse. There's only two choices between tabs and spaces 
("Tabs!" "No, spaces!"). With optional indentation, there has to be some 
sort of marker, like braces or BEGIN/END, so we have:

for item in seq: {
    do_this()
}

for item in seq:
    {
        do_this()
    }

for item in seq: {
    do_this(); }

for item in seq: {
    do_this()
}

for item in seq: 
{ do_this() }

for item in seq: 
    { do_this() }

for item in seq: 
    {
    do_this()
    }

and so on, until your brain explodes.


-- 
Steven

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web