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 1 of 3  [1] 2 3  Next page →

#53220 — Re: semicolon at end of python's statements

[Multipart message — attachments visible in raw view] — view raw

On Wed, Aug 28, 2013 at 8:18 PM, Mohsen Pahlevanzadeh <
mohsen@pahlevanzadeh.org> wrote:

> Dear all,
>
> I'm C++ programmer and unfortunately put semicolon at end of my
> statements in python.
>
> Quesion:
> What's really defferences between putting semicolon and don't put?
>
> Yours,
> Mohsen


I totally understand where you are coming from, but
I have found that the thing I can't get used to is the "indent thing"

Python is a great language, but I always secretly find myself
wishing I could somehow use python, and not deal with the mandatory
"indents"


Sam Fourman Jr.

[toc] | [next] | [standalone]

#53230

On Wed, 28 Aug 2013 22:10:16 -0400, Sam Fourman Jr. wrote:

> On Wed, Aug 28, 2013 at 8:18 PM, Mohsen Pahlevanzadeh <
> mohsen@pahlevanzadeh.org> wrote:
> 
>> Dear all,
>>
>> I'm C++ programmer and unfortunately put semicolon at end of my
>> statements in python.
>>
>> Quesion:
>> What's really defferences between putting semicolon and don't put?
>>
>> Yours,
>> Mohsen
> 
> 
> I totally understand where you are coming from, but I have found that
> the thing I can't get used to is the "indent thing"
> 
> Python is a great language, but I always secretly find myself wishing I
> could somehow use python, and not deal with the mandatory "indents"
> 
>

Yet no doubt you voluntarily indent your c code to make it readable?
it wont take long before you find you don't even think about indentation 
and actually like it  


-- 
All the really good ideas I ever had came to me while I was milking a cow.
		-- Grant Wood

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

#53233

On Thu, Aug 29, 2013 at 7:39 PM, Alister <alister.ware@ntlworld.com> wrote:
> Yet no doubt you voluntarily indent your c code to make it readable?
> it wont take long before you find you don't even think about indentation
> and actually like it

Most of the time, in any language, I will indeed have indentation
matching the syntactic structure of the code (which is what Python
demands). But I like the flexibility of having the indentation under
_my_ control, not under the language's, because my rule is that it
should match the *logical*, not syntactic, structure. For instance,
here's how code looks that iterates over an array:

foreach (some_array, mixed val)
{
    //do something with val
}

And here's how it looks if I want to iterate over a filtered version
of the array:

foreach (some_array, mixed val) if (some_condition)
{
    //do something with val
}

There's no language support required. It reads like a Python
list-comp, simply adding a condition as part of the loop header. But
it technically breaks the indentation rules, and Python doesn't allow
this sort of thing. In Python, this particular example is probably
best done with a generator expression in the for loop, but there are
other cases where I combine two physical structural levels into a
single line and indent level.

ChrisA

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

#53234

[Multipart message — attachments visible in raw view] — view raw

On 29 Aug 2013 10:54, "Chris Angelico" <rosuav@gmail.com> wrote:
>
> foreach (some_array, mixed val) if (some_condition)
> {
>     //do something with val
> }
>

I hope that you don't mind that I have started to use this in JavaScript
back at work. Its foreach loop requires you to do a filter all the time.

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.

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

#53261

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.

-- 
 \       “bash awk grep perl sed, df du, du-du du-du, vi troff su fsck |
  `\                     rm * halt LART LART LART!” —The Swedish BOFH, |
_o__)                                            alt.sysadmin.recovery |
Ben Finney

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

#53263

On Fri, Aug 30, 2013 at 8:17 AM, 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.

That works for the specific example of a for loop (and proves that
it's logical and sensible to iterate over part of a loop). But how
many times has something similar come up - like the
while-loop-that-retains-its-value suggestion a while ago? Sometimes,
the only "new syntax" required is a weakening of the rule that one
thing goes on one line, and then the syntax is simply two block
constructs forming a single loop header.

Also, the genexp version you have above seems to repeat itself a lot.
I'd write that as simply:

for spam in sequence: if predicate(spam):
    process(spam)

though of course, if the processing is a single function call, there
are other ways to lay it out. But assume that the processing is a full
suite.

ChrisA

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

#53274

Ben Finney <ben+python@benfinney.id.au> writes:

> 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.
>     for foo in (spam for spam in sequence if predicate(spam)): …

Better:

    for foo in filter(predicate, sequence):
        process(foo)

-- 
 \       “Corporation, n. An ingenious device for obtaining individual |
  `\       profit without individual responsibility.” —Ambrose Bierce, |
_o__)                                   _The Devil's Dictionary_, 1906 |
Ben Finney

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

#53282

Op 30-08-13 06:55, Ben Finney schreef:
> Ben Finney <ben+python@benfinney.id.au> writes:
> 
>> 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.
>>     for foo in (spam for spam in sequence if predicate(spam)): …
> 
> Better:
> 
>     for foo in filter(predicate, sequence):
>         process(foo)

Well better in what way? You now have to translate a predicate
expression into a predicate function. Which AFAIU was one of
the reasons to move away from map/filter to list comprehension.

As I understand it, python made a move away from map and filter
towards list comprehension. Chris seems to want some of the
possibilities that came with that incorporated into the for
statement. And your suggestion is to go back to the old kind
of filter way.

-- 
Antoon Pardon

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

#53283

On Fri, Aug 30, 2013 at 5:15 PM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> wrote:
> Op 30-08-13 06:55, Ben Finney schreef:
>> Ben Finney <ben+python@benfinney.id.au> writes:
>>
>>> 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.
>>>     for foo in (spam for spam in sequence if predicate(spam)): …
>>
>> Better:
>>
>>     for foo in filter(predicate, sequence):
>>         process(foo)
>
> Well better in what way? You now have to translate a predicate
> expression into a predicate function. Which AFAIU was one of
> the reasons to move away from map/filter to list comprehension.
>
> As I understand it, python made a move away from map and filter
> towards list comprehension. Chris seems to want some of the
> possibilities that came with that incorporated into the for
> statement. And your suggestion is to go back to the old kind
> of filter way.

No, actually Ben's quite right - assuming the predicate is a simple
function, of course (Python's lambda notation is a bit clunky for
comparisons); as of Python 3, filter() is lazy and is pretty much what
I'm doing here. However, that's still a specific answer to a specific
(albeit common) instance of wanting to merge control structures.

ChrisA

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

#53284

Op 30-08-13 09:25, Chris Angelico schreef:
> On Fri, Aug 30, 2013 at 5:15 PM, Antoon Pardon
> <antoon.pardon@rece.vub.ac.be> wrote:
>> Op 30-08-13 06:55, Ben Finney schreef:
>>> Ben Finney <ben+python@benfinney.id.au> writes:
>>>
>>>> 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.
>>>>     for foo in (spam for spam in sequence if predicate(spam)): …
>>>
>>> Better:
>>>
>>>     for foo in filter(predicate, sequence):
>>>         process(foo)
>>
>> Well better in what way? You now have to translate a predicate
>> expression into a predicate function. Which AFAIU was one of
>> the reasons to move away from map/filter to list comprehension.
>>
>> As I understand it, python made a move away from map and filter
>> towards list comprehension. Chris seems to want some of the
>> possibilities that came with that incorporated into the for
>> statement. And your suggestion is to go back to the old kind
>> of filter way.
> 
> No, actually Ben's quite right - assuming the predicate is a simple
> function,

But why should we assume that? Suppose I would like to process all
odd items in a list. A comprehension kind of notation would be

|  for item in lst if item % 2:
|      process items

Which we would have to turn into

|  for item in filter(lambda nr: nr % 2, lst):
|      process items

But AFAIR, one of the driving forces behind the introduction to list
comprehension, and thus a move away from map and filter was to get rid
of the lambda's in this kind of situations.

> of course (Python's lambda notation is a bit clunky for
> comparisons); as of Python 3, filter() is lazy and is pretty much what
> I'm doing here.

Lazy or not, is AFAICS, not a point here.

-- 
Antoon Pardon

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

#53287

[Multipart message — attachments visible in raw view] — view raw

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! While it does its job, it hides the true
intent for filtering beneath a lot of (pun intended) spam. The "if"
particle is nigh undetectable there.

To get around this, I often declare a generator. But I still find it a bit
awkward to have to look up the definition elsewhere, and to waste lines
over something so simple.

I can't say I understand why we don't merge the for loops' syntax with the
comprehension syntax. Even after following the for..while discussion.

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

#53290

In article <mailman.385.1377858745.19984.python-list@python.org>,
 Fábio Santos <fabiosantosart@gmail.com> 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! While it does its job, it hides the true
> intent for filtering beneath a lot of (pun intended) spam. The "if"
> particle is nigh undetectable there.
> 
> To get around this, I often declare a generator. But I still find it a bit
> awkward to have to look up the definition elsewhere, and to waste lines
> over something so simple.
> 
> I can't say I understand why we don't merge the for loops' syntax with the
> comprehension syntax. Even after following the for..while discussion.

+1 on loop comprehensions, for all the reasons Fábios states.

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

#53296

Op 30-08-13 12:53, Roy Smith schreef:
> In article <mailman.385.1377858745.19984.python-list@python.org>,
>  Fábio Santos <fabiosantosart@gmail.com> 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! While it does its job, it hides the true
>> intent for filtering beneath a lot of (pun intended) spam. The "if"
>> particle is nigh undetectable there.
>>
>> To get around this, I often declare a generator. But I still find it a bit
>> awkward to have to look up the definition elsewhere, and to waste lines
>> over something so simple.
>>
>> I can't say I understand why we don't merge the for loops' syntax with the
>> comprehension syntax. Even after following the for..while discussion.
> 
> +1 on loop comprehensions, for all the reasons Fábios states.

Maybe python should just allow more than one control structure on one
line and then considers the end of the suite the end of both controls.
In that case we could just write the following:

  for a in lst: if a % 2:
      treat a
      process a some more
  after loop things.

It technically is not loop comprehension but just nested controls but
by allowing them on the same line it looks close enough like loop
comprehension.

Plus if people have a problem that would best be solved by a while loop
comprehension that would be just as easy.

-- 
Antoon Pardon

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

#53312

On Sat, Aug 31, 2013 at 12:14 AM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> wrote:
> Maybe python should just allow more than one control structure on one
> line and then considers the end of the suite the end of both controls.
> In that case we could just write the following:
>
>   for a in lst: if a % 2:
>       treat a
>       process a some more
>   after loop things.

Exactly what I suggested a while ago :) This is how we got onto this
subject - a discussion of how physical structure and logical structure
can differ.

ChrisA

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

#53315

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.



> While it does its job, it hides
> the true intent for filtering beneath a lot of (pun intended) spam. The
> "if" particle is nigh undetectable there.
> 
> To get around this, I often declare a generator. But I still find it a
> bit awkward to have to look up the definition elsewhere, and to waste
> lines over something so simple.

No need to look up a definition elsewhere, you can put the generator 
right next to the loop:

gen = (spam for spam in sequence if predicate(spam))
for spam in gen:
    process(spam)


But of all the options shown, including the hypothetical for...if, I 
still prefer Option 1, or Option 2 as my second option.



-- 
Steven

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

#53321

On 8/30/2013 8:09 PM, Steven D'Aprano 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)
>
> # 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.

Which is why it has been rejected.

> But of all the options shown, including the hypothetical for...if, I
> still prefer Option 1, or Option 2 as my second option.

Ditto.

I think people would be better off spending more time learning more 
about how to use this incredibly powerful tool we have and less arguing 
for rejected redundant alternatives to what we do have. Just a few days 
ago, after 16 years of Python, I learned something really neat about 
function attributes of instances that made a certain testing problem 
disappear.

-- 
Terry Jan Reedy

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

#53331

Steven D'Aprano writes:

> 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 1.5
for spam in sequence:
    if not predicate(spam): continue
    process(spam)

This saves an indent level.

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

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

#53334

Jussi Piitulainen <jpiitula@ling.helsinki.fi> writes:


> # Option 1.5
> for spam in sequence:
>     if not predicate(spam): continue
>     process(spam)
>
> This saves an indent level.

Just out of interest: is saving an indent level a useful thing?

I wouldn't lay out my code like that just because if you're coming back
to it later and reading through quickly it's (to my mind at least)
easier to miss what's going on.

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

#53340

Paul Rudin writes:
> Jussi Piitulainen writes:
> 
> > # Option 1.5
> > for spam in sequence:
> >     if not predicate(spam): continue
> >     process(spam)
> >
> > This saves an indent level.
> 
> Just out of interest: is saving an indent level a useful thing?

It might be if process(spam) is a more complex statement.

> I wouldn't lay out my code like that just because if you're coming
> back to it later and reading through quickly it's (to my mind at
> least) easier to miss what's going on.

I agree with the general principle but I have actually done the above
(once or twice) precisely because I found it to be the clearer choice
in a particular situation.

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

#53483

On 2013-08-31, Paul Rudin <paul.nospam@rudin.co.uk> wrote:
> Jussi Piitulainen <jpiitula@ling.helsinki.fi> writes:
>
>
>> # Option 1.5
>> for spam in sequence:
>>     if not predicate(spam): continue
>>     process(spam)
>>
>> 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...

-- 
Grant

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web