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

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

New to Python - block grouping (spaces)

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

Contents

  New to Python - block grouping (spaces) Blake McBride <blake1024@gmail.com> - 2015-04-15 21:07 -0700
    Re: New to Python - block grouping (spaces) Paul Rubin <no.email@nospam.invalid> - 2015-04-15 21:48 -0700
    Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-16 14:51 +1000
    Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-16 15:49 +1000
      Re: New to Python - block grouping (spaces) Paul Rubin <no.email@nospam.invalid> - 2015-04-15 23:11 -0700
        Re: New to Python - block grouping (spaces) William Ray Wing <wrw@mac.com> - 2015-04-16 09:00 -0400
      Re: New to Python - block grouping (spaces) BartC <bc@freeuk.com> - 2015-04-16 11:51 +0100
        Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-17 03:10 +1000
          Re: New to Python - block grouping (spaces) Tim Chase <python.list@tim.thechases.com> - 2015-04-16 12:49 -0500
          Re: New to Python - block grouping (spaces) BartC <bc@freeuk.com> - 2015-04-16 22:04 +0100
          Re: New to Python - block grouping (spaces) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-04-17 11:37 +0200
      Re: New to Python - block grouping (spaces) Serhiy Storchaka <storchaka@gmail.com> - 2015-04-16 22:14 +0300
    Re: New to Python - block grouping (spaces) alister <alister.nospam.ware@ntlworld.com> - 2015-04-16 07:46 +0000
      Re: New to Python - block grouping (spaces) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-04-16 10:47 +0200
      Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-16 19:34 +1000
      Re: New to Python - block grouping (spaces) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-04-16 12:09 +0200
        Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-16 20:43 +1000
          Re: New to Python - block grouping (spaces) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-04-16 13:07 +0200
            Re: New to Python - block grouping (spaces)yhoni alister <alister.nospam.ware@ntlworld.com> - 2015-04-16 13:18 +0000
              Re: New to Python - block grouping (spaces)yhoni BartC <bc@freeuk.com> - 2015-04-16 14:44 +0100
                Re: New to Python - block grouping (spaces)yhoni Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-04-16 18:46 +0100
                Re: New to Python - block grouping (spaces)yhoni alister <alister.nospam.ware@ntlworld.com> - 2015-04-16 18:03 +0000
              Re: New to Python - block grouping (spaces)yhoni Chris Angelico <rosuav@gmail.com> - 2015-04-16 23:50 +1000
              Re: New to Python - block grouping (spaces)yhoni Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-04-16 16:09 +0200
                Re: New to Python - block grouping (spaces)yhoni alister <alister.nospam.ware@ntlworld.com> - 2015-04-16 18:04 +0000
          Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-16 23:41 +1000
          Re: New to Python - block grouping (spaces) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-04-16 15:57 +0200
    Re: New to Python - block grouping (spaces) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-04-16 13:17 +0100
    Re: New to Python - block grouping (spaces) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-04-16 14:48 +0200
    Re: New to Python - block grouping (spaces) Simmo <square.steve@gmail.com> - 2015-04-16 14:37 +0100
    Re: New to Python - block grouping (spaces) Blake McBride <blake1024@gmail.com> - 2015-04-16 07:52 -0700
      Re: New to Python - block grouping (spaces) Blake McBride <blake1024@gmail.com> - 2015-04-16 08:01 -0700
        Re: New to Python - block grouping (spaces) alister <alister.nospam.ware@ntlworld.com> - 2015-04-16 18:08 +0000
          Re: New to Python - block grouping (spaces) memilanuk <memilanuk@gmail.com> - 2015-04-16 11:28 -0700
      Re: New to Python - block grouping (spaces) Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-04-16 15:05 +0000
        Re: New to Python - block grouping (spaces) edmondo.giovannozzi@gmail.com - 2015-04-20 03:00 -0700
      Re: New to Python - block grouping (spaces) memilanuk <memilanuk@gmail.com> - 2015-04-16 08:05 -0700
      Re: New to Python - block grouping (spaces) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-04-16 16:05 +0100
        Re: New to Python - block grouping (spaces) CHIN Dihedral <dihedral88888@gmail.com> - 2015-04-19 11:46 -0700
      Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-17 01:03 +1000
      Re: New to Python - block grouping (spaces) Grant Edwards <invalid@invalid.invalid> - 2015-04-16 15:21 +0000
      Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-17 03:41 +1000
        Re: New to Python - block grouping (spaces) Ron Adam <ron3200@gmail.com> - 2015-04-16 14:54 -0400
      EditorConfig for cross-editor consistent code style (was: New to Python - block grouping (spaces)) Ben Finney <ben+python@benfinney.id.au> - 2015-04-17 06:10 +1000
      Re: New to Python - block grouping (spaces) Michael Torrie <torriem@gmail.com> - 2015-04-17 09:44 -0600
        Re: New to Python - block grouping (spaces) Grant Edwards <invalid@invalid.invalid> - 2015-04-17 16:28 +0000
          Re: New to Python - block grouping (spaces) BartC <bc@freeuk.com> - 2015-04-17 18:05 +0100
            Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-17 10:13 -0700
            Re: New to Python - block grouping (spaces) sohcahtoa82@gmail.com - 2015-04-17 11:13 -0700
              Re: New to Python - block grouping (spaces) Marko Rauhamaa <marko@pacujo.net> - 2015-04-17 23:28 +0300
            Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-18 07:10 +1000
            Re: New to Python - block grouping (spaces) Dan Sommers <dan@tombstonezero.net> - 2015-04-18 01:18 +0000
              Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-17 19:22 -0700
                Re: New to Python - block grouping (spaces) BartC <bc@freeuk.com> - 2015-04-19 12:44 +0100
                  Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-19 23:23 +1000
                    Re: New to Python - block grouping (spaces) wxjmfauth@gmail.com - 2015-04-19 07:22 -0700
                  Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-19 07:01 -0700
            Re: New to Python - block grouping (spaces) Michael Torrie <torriem@gmail.com> - 2015-04-17 20:14 -0600
              Re: New to Python - block grouping (spaces) Marko Rauhamaa <marko@pacujo.net> - 2015-04-18 09:53 +0300
            Re: New to Python - block grouping (spaces) Ben Finney <ben+python@benfinney.id.au> - 2015-04-18 12:22 +1000
              Re: New to Python - block grouping (spaces) Larry Hudson <orgnut@yahoo.com> - 2015-04-17 22:28 -0700
              Re: New to Python - block grouping (spaces) Marko Rauhamaa <marko@pacujo.net> - 2015-04-18 10:00 +0300
                Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-18 00:13 -0700
                  Re: New to Python - block grouping (spaces) Marko Rauhamaa <marko@pacujo.net> - 2015-04-18 10:42 +0300
                Re: New to Python - block grouping (spaces) Michael Torrie <torriem@gmail.com> - 2015-04-19 11:15 -0600
                  Re: New to Python - block grouping (spaces) Marko Rauhamaa <marko@pacujo.net> - 2015-04-19 23:41 +0300
                    Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-19 19:00 -0700
                    Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-20 12:54 +1000
                      Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-20 13:05 +1000
                        Re: New to Python - block grouping (spaces) Marko Rauhamaa <marko@pacujo.net> - 2015-04-20 08:09 +0300
              Re: New to Python - block grouping (spaces) BartC <bc@freeuk.com> - 2015-04-19 12:38 +0100
                Re: New to Python - block grouping (spaces) Ben Finney <ben+python@benfinney.id.au> - 2015-04-19 22:59 +1000
                  Re: New to Python - block grouping (spaces) BartC <bc@freeuk.com> - 2015-04-19 22:42 +0100
                    Re: New to Python - block grouping (spaces) Ron Adam <ron3200@gmail.com> - 2015-04-19 19:28 -0400
                    Re: New to Python - block grouping (spaces) Ben Finney <ben+python@benfinney.id.au> - 2015-04-20 09:59 +1000
                      Re: New to Python - block grouping (spaces) BartC <bc@freeuk.com> - 2015-04-20 01:30 +0100
                Re: New to Python - block grouping (spaces) Dave Angel <davea@davea.name> - 2015-04-19 09:18 -0400
                Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-19 23:22 +1000
                Re: New to Python - block grouping (spaces) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-04-19 14:30 +0100
                Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-20 01:15 +1000
                  Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-19 09:03 -0700
                    Re: New to Python - block grouping (spaces) Mel Wilson <mwilson@the-wire.com> - 2015-04-19 17:38 +0000
                    Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-20 03:53 +1000
                      Re: New to Python - block grouping (spaces) Mel Wilson <mwilson@the-wire.com> - 2015-04-19 18:25 +0000
                      Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-19 19:08 -0700
                        Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-20 12:24 +1000
                          Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-19 19:43 -0700
                            Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-20 13:03 +1000
                              Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-19 20:28 -0700
                                Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-20 13:44 +1000
                                  Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-20 19:18 -0700
                            Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-20 20:30 +1000
                              Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-20 04:51 -0700
                                Re: New to Python - block grouping (spaces) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-25 17:42 +0000
                              Re: New to Python - block grouping (spaces) BartC <bc@freeuk.com> - 2015-04-20 13:05 +0100
                              Re: New to Python - block grouping (spaces) wxjmfauth@gmail.com - 2015-04-24 01:50 -0700
                        Re: New to Python - block grouping (spaces) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-04-20 03:38 +0100
                        Re: New to Python - block grouping (spaces) llanitedave <llanitedave@birdandflower.com> - 2015-04-21 08:29 -0700
                          Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-21 10:49 -0700
                            Re: New to Python - block grouping (spaces) llanitedave <llanitedave@birdandflower.com> - 2015-04-21 14:35 -0700
                              Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-21 20:11 -0700
                                Re: New to Python - block grouping (spaces) llanitedave <llanitedave@birdandflower.com> - 2015-04-21 21:05 -0700
                                  Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-22 04:37 -0700
                                    Re: New to Python - block grouping (spaces) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-04-22 13:05 +0100
                      Re: New to Python - block grouping (spaces) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-04-20 20:38 +1200
                        Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-20 20:15 +1000
                    Re: New to Python - block grouping (spaces) Dan Sommers <dan@tombstonezero.net> - 2015-04-19 18:07 +0000
                      Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-20 06:03 +1000
                      Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-19 18:46 -0700
                      Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-20 12:42 +1000
                Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-20 03:46 +1000
                  Re: New to Python - block grouping (spaces) Paul Rubin <no.email@nospam.invalid> - 2015-04-19 13:36 -0700
            Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-24 22:06 -0700
              Re: New to Python - block grouping (spaces) Marko Rauhamaa <marko@pacujo.net> - 2015-04-25 10:27 +0300
                Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-25 09:52 -0700
      Re: New to Python - block grouping (spaces) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-04-24 08:31 +0100
      Re: New to Python - block grouping (spaces) Michael Torrie <torriem@gmail.com> - 2015-04-24 08:03 -0600
    Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-16 10:59 -0700
      Re: New to Python - block grouping (spaces) Rob Gaddi <rgaddi@technologyhighland.invalid> - 2015-04-16 18:45 +0000

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

#89041 — Re: New to Python - block grouping (spaces)yhoni

On 16/04/2015 14:44, BartC wrote:
>
> * I modify code a lot, adding and removing extra nested blocks all the
> time. My editor can't indent or un-indent blocks without a lot of manual
> typing. With block-delimited schemes, this isn't an issue, as temporary
> lack of correct indentation isn't crucial.
>

The year is 2015, not 1520.  Get an editor that can indent and dedent 
code, there's tens if not hundreds of the things, IDLE included.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#89044 — Re: New to Python - block grouping (spaces)yhoni

On Thu, 16 Apr 2015 14:44:15 +0100, BartC wrote:

> On 16/04/2015 14:18, alister wrote:
>> On Thu, 16 Apr 2015 13:07:22 +0200, Antoon Pardon wrote:
> 
>>> Nobody is argueing for arbitrary indentation.
>>
>> May I suggest that you give it a try for a month, perhaps re-writing a
>> small program you already have in a pythonic style (don't simply write
>> c in python) & see if your opinion changes.
> 
> You mean try writing pure Python for a month? Yes, you can get used to
> anything. But that doesn't take away from the issues that some people
> have with its indentation. In my case, that would be the following
> (apart from the extra fragility of the code which you can't argue with):

code fragility? google "goto fail", this could not have happened with 
python.
he try it suggestion was not to get you get used to it but to give you 
enough experience to show that your perceived problems are actually no 
existent FUD

> 
> * I need some closure, some indication of where the end of a block is.
> Otherwise how do I know I'm looking at the last statement, or whether
> there is more on the next page or further down the screen?

oh please if you are not going to look at the code you cant tell in a 
brace delimited language either & if you do open your eyes to scan the 
code it is easier to see in python because the indentation is 100% 
trustworthy where as with C you have to be careful that a brace has not 
been inserted somewhere unexpected.
> 
> Even when I can see what follows the block, I can only infer that this
> is the end of the block because I eventually hit some other arbitrary
> construct with less indentation, not something specifically signalling
> the end of /that/ block.

it is not arbitrary the un-indent is the signal 
> 
> (This would come up when using copy&paste for example. If I've
> accidentally left out the last line of a block, I won't know about it
> until the code later doesn't work.)


> * I modify code a lot, adding and removing extra nested blocks all the
> time. My editor can't indent or un-indent blocks without a lot of manual
> typing.

get a decent editor designed fro programming

> With block-delimited schemes, this isn't an issue, as temporary
> lack of correct indentation isn't crucial.
> 
> (However, given a choice of only brace-delimited blocks, and Python
> style, I'd go for the latter! I have a longer list of complaints for
> C-style braces.)


so you are already 90% of the way there & just need to grasp the fact 
that the braces are redundant if you (sensibly) stick to a rigid 
formatting style


-- 
Kiss your keyboard goodbye!

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

#89025 — Re: New to Python - block grouping (spaces)yhoni

On Thu, Apr 16, 2015 at 11:18 PM, alister
<alister.nospam.ware@ntlworld.com> wrote:
> be warned you may find it creates (or increases ) an extreme dislike for
> C & other languages that require braces & semicolons, it did for me
> (especially the semi-colon!)

I'd just like to add to this that the lack of semicolon in Python
works well because, and *only* because, Python has a lot of other
rules that also are newline-sensitive. ECMAScript code sometimes runs
foul of the "oops I left off a semicolon and my program did something
weird" problem, which Python code almost never will. (Partly that's
because Python prefers to raise SyntaxError in ambiguous cases,
whereas ECMAScript tends to assign meaning to them one way or
another.) If you're writing ECMAScript code, you probably want to keep
all the semis, but in Python, they don't help you at all.

And yet they're both classed as optional. Does that seem right to you? :)

ChrisA

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

#89029 — Re: New to Python - block grouping (spaces)yhoni

On 04/16/2015 03:18 PM, alister wrote:

>
>> As is argueing against a real position instead of making something up.
>> Nobody is argueing for arbitrary indentation.
> May I suggest that you give it a try for a month, perhaps re-writing a 
> small program you already have in a pythonic style (don't simply write c 
> in python) & see if your opinion changes.
>
> if not then other suggestions that python is not a language of choice for 
> you may be appropriate.
>
> be warned you may find it creates (or increases ) an extreme dislike for 
> C & other languages that require braces & semicolons, it did for me 
> (especially the semi-colon!)

I think you are mistaking me for someone else. I have been using python
since before 2000. I went from not liking the forced indentation to not
being bothered with it to not liking it again.

I also think that one doesn't need to discard a language just because one
doesn't like this particular feature. One can think the other characteristics
of the language are positive enough one can live with this small annoyance.

-- 
Antoon Pardon.

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

#89045 — Re: New to Python - block grouping (spaces)yhoni

On Thu, 16 Apr 2015 16:09:13 +0200, Antoon Pardon wrote:

> On 04/16/2015 03:18 PM, alister wrote:
> 
> 
>>> As is argueing against a real position instead of making something up.
>>> Nobody is argueing for arbitrary indentation.
>> May I suggest that you give it a try for a month, perhaps re-writing a
>> small program you already have in a pythonic style (don't simply write
>> c in python) & see if your opinion changes.
>>
>> if not then other suggestions that python is not a language of choice
>> for you may be appropriate.
>>
>> be warned you may find it creates (or increases ) an extreme dislike
>> for C & other languages that require braces & semicolons, it did for me
>> (especially the semi-colon!)
> 
> I think you are mistaking me for someone else. I have been using python
> since before 2000. I went from not liking the forced indentation to not
> being bothered with it to not liking it again.
> 
> I also think that one doesn't need to discard a language just because
> one doesn't like this particular feature. One can think the other
> characteristics of the language are positive enough one can live with
> this small annoyance.

This suggestion was aimed at the Original poster.



-- 
Your mode of life will be changed for the better because of new 
developments.

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

#89023

On Thu, Apr 16, 2015 at 9:07 PM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> wrote:
> On 04/16/2015 12:43 PM, Steven D'Aprano wrote:
>> On Thursday 16 April 2015 20:09, Antoon Pardon wrote:
>>
>>> I beg to differ. The most common occurence is a loop with a break
>>> condition in the middle I would prefer such a loop to be written as
>>> follows:
>>>
>>> repeat:
>>>     some
>>>     code
>>> break_when condition:
>>>     more
>>>     code

The case of a loop structure with its condition in the middle is one
that few languages support, so the physical structure has to be
something like:

goto middle
while not condition:
    more code
    label middle
    some code

or

while True:
    some code
    if condition: break
    more code

or maybe

some code
while not condition:
    more code
    some code

But I'm not sure how you could represent this more appropriately,
regardless of your indentation. Unindenting an "if" in the middle of a
loop doesn't instantly scream "this is the loop header". Using a goto
to jump half way into a loop is a really REALLY bad idea in most
programs (and it's illegal in lots of languages anyway). Repeating the
setup code is fine if it's a single line, but not else.

Similar to this is the capturing condition. Say you want to process
lines until you get to one that consists solely of a full stop. In C,
you can do this (kinda); in Pike, where strings are first-class
objects (like Python, unlike C), you can definitely do it,
syntactically:

while ((line=get_next_line()) != ".")
    process_line(line);

Perfectly legal. Not perfectly readable. In Python, your options are a
helper generator function:

def next_line():
    while True:
        line = get_next_line()
        if line==".": break
        yield line
for line in next_line():
    process_line(line)

or a loop with a critical line of code duplicated above and at the
bottom of the loop (risks 'continue' failure):

line = get_next_line()
while line!=".":
    process_line(line)
    line = get_next_line()

or the "mid-loop break" model, which is what makes this similar to the above:

while True:
    line = get_next_line()
    if line==".": break
    process_line(line)

There's no nice way to spell "grab this and retain it". But again, I'm
not sure how a change of indentation could improve this.

>> That structure makes no sense to me. Why is the "break_when" *outside* of
>> the loop? Why does the "break_when condition" introduce a new block?
>
> How do you mean outside the loop? Do you consider the "else" outside the
> if statement?

The "break_when" is part of the loop structure, not the loop body.
With an entry-checked condition, the loop structure is flush left, and
the loop body is indented:

x, y = 0, 1
while x < y:
    x = (x + y) / 2
    y = f(x)

Some languages have a similar construct for an exit-checked condition, eg REXX:

do until x > y
    /* as above */
end

or BASIC-derived languages:

do
    rem as above
loop while x < y

In all three cases, the condition is on a line that's not indented. So
logically, the mid-checked loop could also go flush left:

do
    some code
while condition
    more code
end

Whether this actually improves readability or not is a separate
question. The "break_when" isn't so much *outside* the loop as simply
*not inside* the loop.

ChrisA

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

#89027

On 04/16/2015 03:41 PM, Chris Angelico wrote:
> The case of a loop structure with its condition in the middle is one
> that few languages support, so the physical structure has to be
> something like:
>
> goto middle
> while not condition:
>     more code
>     label middle
>     some code
>
> or
>
> while True:
>     some code
>     if condition: break
>     more code
>
> or maybe
>
> some code
> while not condition:
>     more code
>     some code
>
> But I'm not sure how you could represent this more appropriately,
> regardless of your indentation. Unindenting an "if" in the middle of a
> loop doesn't instantly scream "this is the loop header". Using a goto
> to jump half way into a loop is a really REALLY bad idea in most
> programs (and it's illegal in lots of languages anyway). Repeating the
> setup code is fine if it's a single line, but not else.
>
I'm not going to argue the merrits of various indentations styles. I
just wanted to protest the notion, that because one indents one's programs
in languages that don't require indentations, one can't have a quarrel
with how python forces you to indent.

A choice was made and although I would have preferred otherwise, I can
live with it.

-- 
Antoon Pardon

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

#89018

On 16/04/2015 05:07, Blake McBride wrote:
> Greetings,
>
> I am new to Python.  I am sorry for beating what is probably a dead horse but I checked the net and couldn't find the answer to my question.
>
> I like a lot of what I've seen in Python, however, after 35 years and probably a dozen languages under my belt, I very strongly disagree with the notion of using white space to delimit blocks.  Not wanting to beat what I believe is probably a dead horse, I have one question.
>
> Is there a utility that will allow me to write Python-like code that includes some block delimiter that I can see, that converts the code into runnable Python code?  If so, where can I find it?
>
> Thanks!
>
> Blake McBride
>

You're not beating a dead horse, it was reduced to a skeleton years ago. 
  I'd either get used to the use of whitespace or find another language.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#89019

On 04/16/2015 06:07 AM, Blake McBride wrote:
> Greetings,
>
> I am new to Python.  I am sorry for beating what is probably a dead horse but I checked the net and couldn't find the answer to my question.
>
> I like a lot of what I've seen in Python, however, after 35 years and probably a dozen languages under my belt, I very strongly disagree with the notion of using white space to delimit blocks.  Not wanting to beat what I believe is probably a dead horse, I have one question.  
>
> Is there a utility that will allow me to write Python-like code that includes some block delimiter that I can see, that converts the code into runnable Python code?  If so, where can I find it?
>
> Thanks!
>
> Blake McBride

If you really want this, and don't like using comments to achieve this,
you can do the folling.

endfor = endif = enddef = endwhile = None

def poweri(a, i):
    if i < 0:
        i = -i
        fac = 1.0 / a
    else:
        fac = a
    endif
    total = 1
    while i:
        if i % 2:
            total *= fac
        endif
        fac *= fac
        i /= 2
    endwhile
    return total
enddef
        

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

#89022

On 16/04/2015 05:07, Blake McBride wrote:
> Greetings,
>
> I am new to Python.  I am sorry for beating what is probably a dead horse but I checked the net and couldn't find the answer to my question.
>
> I like a lot of what I've seen in Python, however, after 35 years and probably a dozen languages under my belt, I very strongly disagree with the notion of using white space to delimit blocks.  Not wanting to beat what I believe is probably a dead horse, I have one question.
>
> Is there a utility that will allow me to write Python-like code that includes some block delimiter that I can see, that converts the code into runnable Python code?  If so, where can I find it?
>
> Thanks!
>
> Blake McBride
>
Interesting point of view.  Likewise, I have used more than a dozen 
languages and I like Python a lot.  Why?  Because the use of indentation 
is (mostly) unambiguous and I find it a lot cleaner than having to check 
whether I need braces, parentheses or whatever delimiters are correct 
for a particular language.  Plus I am relieved of the stylistic debates 
about whether the start-of-block marker starts after the 'IF' or on a 
new line and how the subsequent lines of code should be aligned.

For me, Python is clean and easy to write and, more importantly, I find 
it easier to follow and understand code written by others.

Steve Simmons

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

#89031

Thanks for all the responses.  I especially like the Pike pointer.  To be clear:

1.  I don't think languages should depend on invisible elements to determine logic.

2.  Having been an employer, it is difficult to force programmers to use any particular editor or style.  Different editors handle tabs and spaces differently.  This is all a bloody nightmare with Python.

3.  Languages that use braces (or the like) can be run through a program beautifier to correct the indentation.  You are just screwed in Python.  So, Python may be a cute language for you to use as an individual, but it is unwieldy in a real development environment.

4.  Language beautifiers used on bracey languages removes all arguments in favor of an off-side language.

Blake McBride

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

#89032

As a side note, I bought a few books on Python from Amazon for use on my Kindle.  At least one of the books has the formatting for the Kindle messed up rendering the meaning of the program useless.

Case in point.

Blake

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

#89046

On Thu, 16 Apr 2015 08:01:45 -0700, Blake McBride wrote:

> As a side note, I bought a few books on Python from Amazon for use on my
> Kindle.  At least one of the books has the formatting for the Kindle
> messed up rendering the meaning of the program useless.
> 
> Case in point.
> 
> Blake

A poor quality book
You can write bad books for any language

I do sympathise as this is something you cannot easily tell before 
purchase (although there as so many good guides available on line I don't 
think there is much benefit in buying a book)


-- 
Talking much about oneself can also be a means to conceal oneself.
		-- Friedrich Nietzsche

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

#89047

On 04/16/2015 11:08 AM, alister wrote:
> On Thu, 16 Apr 2015 08:01:45 -0700, Blake McBride wrote:
>
>> As a side note, I bought a few books on Python from Amazon for use on my
>> Kindle.  At least one of the books has the formatting for the Kindle
>> messed up rendering the meaning of the program useless.
>>
>> Case in point.
>>
>> Blake
>
> A poor quality book
> You can write bad books for any language
>
> I do sympathise as this is something you cannot easily tell before
> purchase (although there as so many good guides available on line I don't
> think there is much benefit in buying a book)

Some publishers are worse about this than others.  Packt 
(www.packtpub.com) has some decent material, but absolutely incompetent 
when it comes to formatting python code in a Kindle .mobi file.  I don't 
think I've ever seen *any* errata published for any of their books.  I 
long since decided that anything I see from Packt that I want to read... 
I might find it on Amazon, but I go to Packt's site and purchase the 
PDF.  They have a harder time screwing that up, apparently.

O'Reilly, on the other hand, gets it right.  Period.


-- 
Shiny!  Let's be bad guys.

Reach me @ memilanuk (at) gmail dot com

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

#89033

On 2015-04-16, Blake McBride <blake1024@gmail.com> wrote:
> 2.  Having been an employer, it is difficult to force programmers to
> use any particular editor or style.  Different editors handle tabs
> and spaces differently.  This is all a bloody nightmare with Python.
>
> 3.  Languages that use braces (or the like) can be run through a
> program beautifier to correct the indentation.  You are just screwed
> in Python.  So, Python may be a cute language for you to use as an
> individual, but it is unwieldy in a real development environment.

Yes, you are quite right - no employers have ever used Python, nor
has anybody ever used Python in a "real development environment".
The issues you raise are novel and have not been thought about before.

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

#89212

I work in research and mainly use Fortran and Python.

I haven't had any problem with the python indentation. I like it, I find it simple and easy.

Well, sometimes I may forget to close an IF block with an ENDIF, in Fortran, so used I am on ending a block just decreasing the indentation, not a big problem actually (always spotted by the compiler).


 

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

#89034

On 04/16/2015 07:52 AM, Blake McBride wrote:
> Thanks for all the responses.  I especially like the Pike pointer.
> To be clear:
>
> 1.  I don't think languages should depend on invisible elements to
> determine logic.
>
> 2.  Having been an employer, it is difficult to force programmers to
> use any particular editor or style.  Different editors handle tabs
> and spaces differently.  This is all a bloody nightmare with Python.
>
> 3.  Languages that use braces (or the like) can be run through a
> program beautifier to correct the indentation.  You are just screwed
> in Python.  So, Python may be a cute language for you to use as an
> individual, but it is unwieldy in a real development environment.
>
> 4.  Language beautifiers used on bracey languages removes all
> arguments in favor of an off-side language.
>
> Blake McBride
>

While I certainly don't have your background or depth of experience...
do you really think that over the last 20 odd years that Python has
been around that #2 and #3 have not been hammered out?

Honestly, this is starting to smell more and more like a troll...

-- 
Shiny!  Let's be bad guys.

Reach me @ memilanuk (at) gmail dot com

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

#89035

On 16/04/2015 15:52, Blake McBride wrote:

> So, Python may be a cute language for you to use as an individual, but it is unwieldy in a real development environment.
>

Thanks for this, one of the funniest comments I've read here in years. 
It's good to see that new people share the humourous side of the Python 
programming culture.  Long may it continue.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#89168

On Thursday, April 16, 2015 at 11:06:28 PM UTC+8, Mark Lawrence wrote:
> On 16/04/2015 15:52, Blake McBride wrote:
> 
> > So, Python may be a cute language for you to use as an individual, but it is unwieldy in a real development environment.
> >
> 
> Thanks for this, one of the funniest comments I've read here in years. 
> It's good to see that new people share the humourous side of the Python 
> programming culture.  Long may it continue.
> 
> -- 
> My fellow Pythonistas, ask not what our language can do for you, ask
> what you can do for our language.
> 
> Mark Lawrence

Python is a cross-platform computer
language with dynamical types, 
functional programming featuers, oops, and generic programming featuers designed in the language.

Now the generic part is the main
progress in the software and IT
sectors 

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

#89036

On Fri, Apr 17, 2015 at 12:52 AM, Blake McBride <blake1024@gmail.com> wrote:
> 2.  Having been an employer, it is difficult to force programmers to use any particular editor or style.  Different editors handle tabs and spaces differently.  This is all a bloody nightmare with Python.
>
> 3.  Languages that use braces (or the like) can be run through a program beautifier to correct the indentation.  You are just screwed in Python.  So, Python may be a cute language for you to use as an individual, but it is unwieldy in a real development environment.
>

If you're prepared to run a beautifier on your employees' code, you
should have no problem requiring that they adopt a syntactically-legal
style. You're already throwing away any option of indentation not
matching the physical structure of the code, so why not simply have
the indentation define the physical structure?

ChrisA

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

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

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

csiph-web