New to Python - block grouping (spaces)

classic Classic list List threaded Threaded
118 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

New to Python - block grouping (spaces)

Blake McBride
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


Reply | Threaded
Open this post in threaded view
|

New to Python - block grouping (spaces)

Paul Rubin-7
Blake McBride <blake1024 at gmail.com> writes:
> probably a dozen languages under my belt, I very strongly disagree
> with the notion of using white space to delimit blocks.

I suggest giving it a try before deciding something like that.  I don't
guarantee you'll come around, but a lot of people decide after a while
that they like it after all.

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

I'm not aware of one.  People who don't like Python's indentation syntax
tend to choose other languages.


Reply | Threaded
Open this post in threaded view
|

New to Python - block grouping (spaces)

Chris Angelico
In reply to this post by Blake McBride
On Thu, Apr 16, 2015 at 2:07 PM, Blake McBride <blake1024 at gmail.com> wrote:
> 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?
>

Python has a mechanic for handling syntax changes in a
backward-compatible way: the __future__ module. Some handy reading:

https://docs.python.org/3/library/__future__.html
https://www.python.org/dev/peps/pep-0236/
https://docs.python.org/3/reference/simple_stmts.html#future

To make use of this, put this line at the top of your program:

from __future__ import braces

Give it a try, I'll wait for you. Or paste that in at the interactive
interpreter prompt.

Done it?

Okay. Now you understand how Python's developers feel about this kind
of thing :)

What you may want to consider is a Python-like language that uses a
different syntax: Pike. It's semantically very similar to Python, but
syntactically similar to C. Learn both, and then you'll understand a
bit more of the debate. I used to be firmly on the side of braces, but
not so much now; Python's use of indentation eliminates some
redundancy (since, after all, you're probably going to be indenting
correctly anyway). Yes, it's using something syntactically that you
might think of as pure formatting (leading whitespace on a line), but
it's not fundamentally illogical or anything.

You can, of course, come up with a syntax for a "brace-blocked
Python", and precompile it into actual runnable Python code. That'd be
fairly straight-forward. But the question is, why do it? You wouldn't
be able to take much advantage of it without making a whole lot of
other changes, which would basically mean turning it into a completely
different language, and then there's not a lot of point using Python
behind the scenes. For instance, Python has declared mutable globals,
whereas bracey languages usually have declared locals, or in the case
of PHP, declared globals (mutable or read-only). Which way would you
do it? And what about semicolons? If you're going to allow blocks of
code to be defined by visible characters instead of whitespace,
wouldn't it make sense to do the same with statements? In Python, for
instance, you can't do this:

if x==1: for i in range(3): print(i)

but you can do this:

if x==1: print(1); print(2);

and they'll both be governed by the 'if'.

I strongly recommend NOT doing a half-way change like this, just
adding braces and nothing more. All you'll end up doing is wishing
that Python were like C in some other way, and then another, and then
another, and you'll find yourself hating Python. Learn Python the way
Python is meant to be, and learn a different language if you like its
semantics but not its syntax.

And I'm happy to talk to you off-list about Pike. In my opinion, it
and Python are the two best programming languages in the world.

ChrisA


Reply | Threaded
Open this post in threaded view
|

New to Python - block grouping (spaces)

Steven D'Aprano-11
In reply to this post by Blake McBride
On Thursday 16 April 2015 14: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?

Python already supports this with the optional "block delimiter" sigil. For
example, if you like braces, you can write:


def function(x):
#{
    if x > 1:
        #{
        print "x bigger than 1"
        #}
    else:
    #{
        print "x smaller than or equal to 1"
        while x <= 1:  #{
            x += 1  #}
        #}
    return x
#}

Notice that Python is clever enough to allow many brace styles, or even
allow you to invent your own style.

If you prefer Pascal style, Python supports that too:

def function(x):
    # BEGIN
    return x
    # END

You can even localise it:

def function(x):  # ANFANGEN
    return x
    # BEENDEN


Best of all, Python's parser includes an advanced "Do What I Mean" expert
system which can infer the intended block grouping from the indentation
alone, even when braces are missing or in the wrong position. Unlike C,
Python will do the right thing here:


if condition:
    do_this()
    do_that()


No more bugs from accidentally forgetting to use optional braces!



Sorry for the flippant response, but it's 2015, not 1995, and the question
about the Offside Rule is not just a dead horse but it is positively
fossilized.

https://en.wikipedia.org/wiki/Off-side_rule

I'm not aware of any pre-processor tools for Python that will syntactically
check that added braces match the indentation. Such a tool would be
unPythonic: if they match, the braces are redundant and are not needed, and
if they do not match, then the compiler (or preprocessor) should not guess
whether the indentation is right or the braces are right. But if you enforce
the rule that braces must match indentation, then the braces are redundant!

If you find such a preprocessor, or write your own, feel free to use it. But
you won't get any respect from experienced Python programmers: we use Python
in part to get away from braces, we're not chomping at the bit to put them
back in.

I'm aware that Coffeescript provides a brace-free wrapper around Javascript;
I'm not aware of any wrapper that *adds* braces to a language without them.
I suspect such a thing would be of limited use and even less popularity. But
feel free to try developing one, I could be wrong!



--
Steve



Reply | Threaded
Open this post in threaded view
|

New to Python - block grouping (spaces)

Paul Rubin-7
Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:
> I'm aware that Coffeescript provides a brace-free wrapper around Javascript;
> I'm not aware of any wrapper that *adds* braces to a language without them.

You're not old enough to remember Ratfor ;-)


Reply | Threaded
Open this post in threaded view
|

New to Python - block grouping (spaces)

alister
In reply to this post by Blake McBride
On Wed, 15 Apr 2015 21:07:45 -0700, 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.

as others have suggested this is a core to python as it enforces
readability. Many new python programmes find it strange but usually take
to it quite quickly.

what I find strange is that although these programmers initially disliked
forced indentation they were voluntarily indenting there existing code
anyway. Take a look at your existing code base & see if this would indeed
be the case.

Stephens suggestion of using comments @ the start & end of your blocks
may be useful during the learning phase.





--
Battle, n.:
        A method of untying with the teeth a political knot that
        will not yield to the tongue.
                -- Ambrose Bierce


Reply | Threaded
Open this post in threaded view
|

New to Python - block grouping (spaces)

Antoon Pardon
On 04/16/2015 09:46 AM, alister wrote:

> what I find strange is that although these programmers initially disliked
> forced indentation they were voluntarily indenting there existing code
> anyway. Take a look at your existing code base & see if this would indeed
> be the case.

The problem is that the logical structure one has in one's head is not always
the same as the physical structure one has to implement in. I prefer the
indentation of my program to reflect the former instead of the latter. That
is impossible in python.

This problem sometimes shows up when possible new programming structures are
discussed and the structure is discareded, not because it lacks merrit but
because it can't me made to fit into the forced indentation mold of python.



Reply | Threaded
Open this post in threaded view
|

New to Python - block grouping (spaces)

Chris Angelico
On Thu, Apr 16, 2015 at 6:47 PM, Antoon Pardon
<antoon.pardon at rece.vub.ac.be> wrote:

> On 04/16/2015 09:46 AM, alister wrote:
>
>> what I find strange is that although these programmers initially disliked
>> forced indentation they were voluntarily indenting there existing code
>> anyway. Take a look at your existing code base & see if this would indeed
>> be the case.
>
> The problem is that the logical structure one has in one's head is not always
> the same as the physical structure one has to implement in. I prefer the
> indentation of my program to reflect the former instead of the latter. That
> is impossible in python.

I agree, but as it turns out, the number of times when this actually
makes a difference are diminishingly few. The most warpedly correct
indentation I've ever done was in PHP, where I used a triply-nested
structure of switch/case blocks to simulate a logical structure that
in Python would simply be a series of top-level functions - or *maybe*
a series of class definitions with methods in them. So if I were doing
the same logical structure in Python, I wouldn't mind the indentation
matching the physical structure, because it'd be sufficiently close.

ChrisA


Reply | Threaded
Open this post in threaded view
|

New to Python - block grouping (spaces)

Antoon Pardon
On 04/16/2015 11:34 AM, Chris Angelico wrote:

> On Thu, Apr 16, 2015 at 6:47 PM, Antoon Pardon
> <antoon.pardon at rece.vub.ac.be> wrote:
>> On 04/16/2015 09:46 AM, alister wrote:
>>
>>> what I find strange is that although these programmers initially disliked
>>> forced indentation they were voluntarily indenting there existing code
>>> anyway. Take a look at your existing code base & see if this would indeed
>>> be the case.
>> The problem is that the logical structure one has in one's head is not always
>> the same as the physical structure one has to implement in. I prefer the
>> indentation of my program to reflect the former instead of the latter. That
>> is impossible in python.
> I agree, but as it turns out, the number of times when this actually
> makes a difference are diminishingly few.

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

Actually I would prefer a more elaborate scheme but would be contend with
a possibility like the above. IMO this is the most occuring pattern where
the logical structure doesn't match the physical structure and it is not
occuring relevantly less now.



Reply | Threaded
Open this post in threaded view
|

New to Python - block grouping (spaces)

Steven D'Aprano-11
In reply to this post by Chris Angelico
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


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?



> Actually I would prefer a more elaborate scheme but would be contend with
> a possibility like the above. IMO this is the most occuring pattern where
> the logical structure doesn't match the physical structure and it is not
> occuring relevantly less now.


Judging by the above example, I think it may be a good thing that Python
doesn't allow "more elaborate" indentation schemes.

repeat:
    do this
    do that
                  do something else important
          and this
sometimes this
          also this
                             but don't do this
  unless today is Tuesday
               # end loop



Simplicity is a virtue.




--
Steve



Reply | Threaded
Open this post in threaded view
|

New to Python - block grouping (spaces)

BartC-3
In reply to this post by Steven D'Aprano-11
On 16/04/2015 06:49, Steven D'Aprano wrote:
> On Thursday 16 April 2015 14:07, Blake McBride wrote:

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

> No more bugs from accidentally forgetting to use optional braces!

You get bugs instead from mistakenly using the wrong indentation or
losing the correct indentation (accidentally pressing the wrong key for
example).

> If you find such a preprocessor, or write your own, feel free to use it. But
> you won't get any respect from experienced Python programmers: we use Python
> in part to get away from braces, we're not chomping at the bit to put them
> back in.
>
> I'm aware that Coffeescript provides a brace-free wrapper around Javascript;
> I'm not aware of any wrapper that *adds* braces to a language without them.
> I suspect such a thing would be of limited use and even less popularity. But
> feel free to try developing one, I could be wrong!

I used a wrapper a couple of years ago that allowed me to write in my
own Algol68-style syntax and produce Python as output. A short example
might have this as input:

proc start=
   to 10 do
     println "Hello World"
   od
end

and produced:

import sys
import math
import copy

def start():
     _tmp1=10
     while _tmp1>0:
         sys.stdout.write(str("Hello World"))
         sys.stdout.write("\n")
         _tmp1=_tmp1-1

start()

(It actually worked quite well, for small programs, and I managed to get
the same input converted to Lisp and Lua too. Also, for very simple
programs, to C, but this requires static type declarations which are
ignored for Python output.

However the main problem was that Python was too semantically different
from the way I normally used the input language, and now that language
is self-contained and does its own thing.)

This wrapper took the form of a proper parser for the input, producing
an abstract syntax tree, which was then written out in the output syntax
of choice.

Where the input is already nearly Python, then it can much simpler, but
it can't do so much checking. If there is a 1:1 correspondence between
line numbers of input and output, then it makes it easier to match any
Python errors with the original not-quite-Python source code.

I've used this approach to add Algol-68 block delimiters (and change a
few other things I found annoying) to C code.

--
Bartc


Reply | Threaded
Open this post in threaded view
|

New to Python - block grouping (spaces)

Antoon Pardon
In reply to this post by Steven D'Aprano-11
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
>
> 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?

>> Actually I would prefer a more elaborate scheme but would be contend with
>> a possibility like the above. IMO this is the most occuring pattern where
>> the logical structure doesn't match the physical structure and it is not
>> occuring relevantly less now.
>
> Judging by the above example, I think it may be a good thing that Python
> doesn't allow "more elaborate" indentation schemes.
>
> repeat:
>     do this
>     do that
>                   do something else important
>           and this
> sometimes this
>           also this
>                              but don't do this
>   unless today is Tuesday
>                # end loop
>
>
>
> Simplicity is a virtue.

As is argueing against a real position instead of making something up.
Nobody is argueing for arbitrary indentation.



Reply | Threaded
Open this post in threaded view
|

New to Python - block grouping (spaces)

Mark Lawrence
In reply to this post by Blake McBride
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



Reply | Threaded
Open this post in threaded view
|

New to Python - block grouping (spaces)

Antoon Pardon
In reply to this post by Blake McBride
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
       



Reply | Threaded
Open this post in threaded view
|

New to Python - block grouping (spaces)

William Ray Wing
In reply to this post by Paul Rubin-7

> On Apr 16, 2015, at 2:11 AM, Paul Rubin <no.email at nospam.invalid> wrote:
>
> Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:
>> I'm aware that Coffeescript provides a brace-free wrapper around Javascript;
>> I'm not aware of any wrapper that *adds* braces to a language without them.
>
> You're not old enough to remember Ratfor ;-)
> --
> https://mail.python.org/mailman/listinfo/python-list

HO Boy - Rational FORTRAN!  Right up there with WatFOR (Waterloo FORTRAN for you youngsters).  It was interpreted FORTRAN.  Used teaching new programmers back in the day because it kept them from crashing the system.

Bill

Reply | Threaded
Open this post in threaded view
|

New to Python - block grouping (spaces)yhoni

alister
In reply to this post by Steven D'Aprano-11
On Thu, 16 Apr 2015 13:07:22 +0200, Antoon Pardon 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
>>
>> 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?
>
>>> Actually I would prefer a more elaborate scheme but would be contend
>>> with a possibility like the above. IMO this is the most occuring
>>> pattern where the logical structure doesn't match the physical
>>> structure and it is not occuring relevantly less now.
>>
>> Judging by the above example, I think it may be a good thing that
>> Python doesn't allow "more elaborate" indentation schemes.
>>
>> repeat:
>>     do this do that
>>                   do something else important
>>           and this
>> sometimes this
>>           also this
>>                              but don't do this
>>   unless today is Tuesday
>>                # end loop
>>
>>
>>
>> Simplicity is a virtue.
>
> 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!)



--
If in any problem you find yourself doing an immense amount of work, the
answer can be obtained by simple inspection.


Reply | Threaded
Open this post in threaded view
|

New to Python - block grouping (spaces)

Steve Simmons
In reply to this post by Blake McBride
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


Reply | Threaded
Open this post in threaded view
|

New to Python - block grouping (spaces)

Chris Angelico
In reply to this post by Antoon Pardon
On Thu, Apr 16, 2015 at 9:07 PM, Antoon Pardon
<antoon.pardon at 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


Reply | Threaded
Open this post in threaded view
|

New to Python - block grouping (spaces)yhoni

BartC-3
In reply to this post by alister
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):

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

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.

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

--
Bartc


Reply | Threaded
Open this post in threaded view
|

New to Python - block grouping (spaces)yhoni

Chris Angelico
In reply to this post by alister
On Thu, Apr 16, 2015 at 11:18 PM, alister
<alister.nospam.ware at 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


1234 ... 6