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

[Paul Rubin]

Blake McBride <blak...@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.

[Chris Angelico]

On Thu, Apr 16, 2015 at 2:07 PM, Blake McBride <blak...@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

[Steven D'Aprano]

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

[Paul Rubin]

Steven D'Aprano <steve+comp....@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 ;-)

[alister]

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

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

[Chris Angelico]

On Thu, Apr 16, 2015 at 6:47 PM, Antoon Pardon
<antoon...@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

[Antoon Pardon]

On 04/16/2015 11:34 AM, Chris Angelico wrote:
> On Thu, Apr 16, 2015 at 6:47 PM, Antoon Pardon
> <antoon...@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.

[Steven D'Aprano]

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

[BartC]

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

[Antoon Pardon]

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.

[Mark Lawrence]

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

[Antoon Pardon]

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

[alister]

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.

[Simmo]

On 16/04/2015 05:07, Blake McBride wrote:

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

[Chris Angelico]

On Thu, Apr 16, 2015 at 9:07 PM, Antoon Pardon
<antoon...@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

[BartC]

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

[Chris Angelico]

On Thu, Apr 16, 2015 at 11:18 PM, alister
<alister.n...@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

[Antoon Pardon]

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

[William Ray Wing]

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

[Antoon Pardon]

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.

[Blake McBride]

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

[Blake McBride]

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

[Jon Ribbens]

On 2015-04-16, Blake McBride <blak...@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.

[memilanuk]

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

[Mark Lawrence]

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.

[Chris Angelico]

On Fri, Apr 17, 2015 at 12:52 AM, Blake McBride <blak...@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

[Grant Edwards]

On 2015-04-16, Blake McBride <blak...@gmail.com> 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.

I had the same attitude when I first tried Python 15 years ago. But,
Python was the only free language implimentation I could find for
Windows that had all the features to allow me to easily write a
program to suck e-mail messages out of Outlook via DCOM and shove them
over to an SMTP server.

After a few days of use, I was a firm believer in semantically
significant indentation (and have been ever since).

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

It's an even _worse_ problem for C, PHP, Javascript, et al. At least
Python requires some semblance of order and method. Those other
languages allow complete anarchy, and any time developer A has to
read/edit code from devloper B, it wastes all sorts of time.

> 3. Languages that use braces (or the like) can be run through a
> program beautifier to correct the indentation.

With Python, there's no need. The indenation is _already_ correct.

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

Ah. That explains why Google uses it so much.

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

As trolls go, I don't think this rates much above a C-.

--
Grant Edwards grant.b.edwards Yow! VICARIOUSLY experience
at some reason to LIVE!!
gmail.com

[Steven D'Aprano]

On Thu, 16 Apr 2015 08:51 pm, BartC wrote:

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

That's nothing! Python gives you absolutely no protection from accidentally
typing:


x += 1

when you actually wanted:

y -= 2


And there there was the time I edited some code written by my boss. I
intended to write a comment:

# FIXME: this function is a little slow and should be optimized.

but I hit the wrong key a couple of times and wrote:

# This is a steaming pile of guano written by a drooling
# moron who shouldn't be allowed near a computer. It needs
# to be deleted with prejudice, and the hard drive and all
# backup tapes set on fire just to be sure.


As I'm sure you will agree, it is an easy mistake to make.


I'm not impressed by arguments "braces protect you from accidentally hitting
tab too many times (or too few)". Um, okay. Don't people read their own
code? How do you not notice that you've indented it wrongly?

To my mind, the argument from "hitting tab too many times" is like tying a
double-bed mattress to your head in case an eagle flying overhead drops a
tortoise on your head.


The great thing about Off-side rule languages like Python is that the
structure of code is easy to see:


code code code code code code code
code
code code code
code code code
code code code
code
code
code
code code code
code code
code code
code code
code
code


while braces without indentation are horribly opaque:

code code code code code code code { code } code code code { code
code code { code code code } code { code { code { code code code
{ code code } code code { code code } } } } code } code



It's true that if a tool mangles your source code and deletes all your
indentation, you cannot mechanically fix the problem without understanding
the intent of the source code. But if a tool mangles your source code by
deleting words starting with "w", the same applies. Don't use broken tools.



--
Steven

[lco...@go2france.com]

On Fri, Apr 17, 2015 at 12:52 AM, Blake McBride <blak...@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

The war of the whitespaces rages on among programmers

http://www.itworld.com/article/2909268/the-war-of-the-whitespaces-rages-on-among-programmers.html?phint=newt%3Ditworld_today&phint=idg_eid%3D997c2c0be180eb9bc32d6211712db4cb#tk.ITWNLE_nlt_today_2015-04-16

[Steven D'Aprano]

On Fri, 17 Apr 2015 12: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.

Icompletelyagreethatinvisibleelementsareterribleandalllanguagesshouldeliminatethemcompletely.Anythingelsewillharmreadabilityandmakesitmuchhardertofollowthelogic.

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

Do you really expect us to believe for a microsecond that the choice
between "4 spaces" or "tab" is worse than the C brace wars?

If you, as an employer, cannot get your programmers to follow your in-house
style requirements, then what instructions can you get them to follow? Do
they even bother to show up? Other than on "lunch is on the boss" day?



--
Steven

[Mark Lawrence]

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.

[Tim Chase]

On 2015-04-17 03:10, Steven D'Aprano wrote:
> And there there was the time I edited some code written by my boss.
> I intended to write a comment:
>
> # FIXME: this function is a little slow and should be optimized.
>
> but I hit the wrong key a couple of times and wrote:
>
> # This is a steaming pile of guano written by a drooling
> # moron who shouldn't be allowed near a computer. It needs
> # to be deleted with prejudice, and the hard drive and all
> # backup tapes set on fire just to be sure.
>
> As I'm sure you will agree, it is an easy mistake to make.

Phew, glad I'm not the only one to do that. Fortunately, I had one
of those code-reformatters the OP talks about, and it fixed the
mistake for me. :-)

-tkc

[Rustom Mody]

On Thursday, April 16, 2015 at 9:37:57 AM UTC+5:30, 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.

Kudos for making dead horses fly [33 posts in 13 hours and going strong]

[alister]

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!

[alister]

This suggestion was aimed at the Original poster.



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

[alister]

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

[memilanuk]

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.

[Rob Gaddi]

Catapult and a dream, man. Catapult and a dream.



--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

[Serhiy Storchaka]

On 16.04.15 08:49, Steven D'Aprano wrote:
> 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.

https://hg.python.org/cpython/raw-file/default/Tools/scripts/pindent.py

[Ben Finney]

Chris Angelico <ros...@gmail.com> writes:

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

For teams with a mixture of text editors in use, there are even tools
nowadays to help everyone's text editor enforce consistency of the
fundamentals in the code.

One which is ready now and already widely adopted is EditorConfig:

EditorConfig helps developers define and maintain consistent coding
styles between different editors and IDEs. The EditorConfig project
consists of a file format for defining coding styles and a
collection of text editor plugins that enable editors to read the
file format and adhere to defined styles. EditorConfig files are
easily readable and they work nicely with version control systems.

<URL:http://editorconfig.org/>

--
\ “I was in Las Vegas, at the roulette table, having a furious |
`\ argument over what I considered to be an odd number.” —Steven |
_o__) Wright |
Ben Finney

[BartC]

On 16/04/2015 18:10, Steven D'Aprano wrote:
> On Thu, 16 Apr 2015 08:51 pm, BartC wrote:
>
>> 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).
>
> That's nothing! Python gives you absolutely no protection from accidentally
> typing:
>
>
> x += 1
>
> when you actually wanted:
>
> y -= 2

>

> As I'm sure you will agree, it is an easy mistake to make.

I meant hitting Backspace or Delete.

But also, sometimes you post code to Usenet and you find leading tabs
have been stripped out. With Python code, that's problematical.

> I'm not impressed by arguments "braces protect you from accidentally hitting
> tab too many times (or too few)". Um, okay. Don't people read their own
> code? How do you not notice that you've indented it wrongly?

Take:

if cond:
stmt1
stmt2
stmt3

and:

if cond:
stmt1
stmt2
stmt3

which one is correct? Is there a tab too many, or one too few? Or two
too many? Now, much as I dislike C-style braces, at least it is a little
more resilient:

if (cond) {
stmt1;
stmt2;
stmt3;
}

or:

if (cond) {
stmt1;
stmt2;
}
stmt3;

One 'if' clearly has three statements, and the other has two, and you
are confident enough to fix the tabbing errors without consequences.

> while braces without indentation are horribly opaque:
>
> code code code code code code code { code } code code code { code
> code code { code code code } code { code { code { code code code
> { code code } code code { code code } } } } code } code

It seems to work well enough with expressions:

x = (a * (b+c) * d) / e

--
Bartc

[Ron Adam]

On 04/16/2015 01:41 PM, Steven D'Aprano 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.
>
> Do you really expect us to believe for a microsecond that the choice
> between "4 spaces" or "tab" is worse than the C brace wars?

You know I've never thought braces where the problem in a language, and in
python, not having them isn't a problem either.

The reason I dislike C is due to the amount of boiler plate and the low
level of code, which requires managing memory, declaring prototypes and
including headers. All of which I think are much more troublesome and
harder to get right than any amount of braces.

Both sides have advantages, but Python's design is meant to represent code
in an easier to see and read way. Representing blocks by indention is
consistent with that. (And so is outlines in written language.)

I could equally like a language where blocks are literal code objects that
can be assigned to names. In that case the block delimiters would be
consistent with that language design and that would be perfectly fine to
me. The code would be representing what it does in an expected and useful way.

block = {statement_1; statement_2; ...}

The cases in between seem a bit unclean to me however. Where braces are
used to define blocks that aren't exposed. I think it's ok, but it also
seems a bit unclean to me. Adding more noise than necessary to the code.
But I understand at some time, when a language was designed it may have
been that it made parsing the language simpler. (it does.) Or it may have
just been the language designers preference at that time. <shrug>

But still, I think the whole braces are good/evil is over stated. There
are lots of more important things in languages to consider.

Cheers,
Ron

[Antoon Pardon]

Op 16-04-15 om 19:10 schreef Steven D'Aprano:

> On Thu, 16 Apr 2015 08:51 pm, BartC wrote:
>
>> 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).
> That's nothing! Python gives you absolutely no protection from accidentally
> typing:
>
>
> x += 1
>
> when you actually wanted:
>
> y -= 2

I find this a bit disingenuous. Each time assignment as an expression comes
up, so that it would be possible to have an assignment in a if or while
condition, few of the regulars seem to have a problem with the argument that
the current choice protects against a particular kind of bug.

The fact that braces protect against a kind of bug you care less about,
is just your preference. That doesn't mean a different preference is
somehow worthy of ridicule.

Mistakes of all kinds happen and I see no reason to ridicule someone for
wishing protect against one kind of mistake, while yourself having the
protection you like.

--
Antoon Pardon

[Michael Torrie]

While it appears that you had already made up your mind about the matter
long before posting, and perhaps was just looking for vindication, I
feel that some of the snide replies you got were just not tremendously
professional. However, it may be that people recognized that you likely
had made up your mind already, and posted accordingly.

[Grant Edwards]

On 2015-04-17, Michael Torrie <tor...@gmail.com> wrote:
> On 04/16/2015 08:52 AM, Blake McBride wrote:
>> Thanks for all the responses. I especially like the Pike pointer.
>> To be clear:
>

[troll bait elided]

> While it appears that you had already made up your mind about the
> matter long before posting, and perhaps was just looking for
> vindication, I feel that some of the snide replies you got were just
> not tremendously professional.

There are people who post to Usenet professionally? And I've been
doing it all these years _for_free_? And, it's not like there's some
sort of Olympics for which I needed to maintain my amateur standing.

> However, it may be that people recognized that you likely had made up
> your mind already, and posted accordingly.

I think most of us just assumed he was just trolling and were playing
along for the fun of it.

--
Grant Edwards grant.b.edwards Yow! As President I have
at to go vacuum my coin
gmail.com collection!

[BartC]

On 17/04/2015 17:28, Grant Edwards wrote:
> On 2015-04-17, Michael Torrie <tor...@gmail.com> wrote:

>> However, it may be that people recognized that you likely had made up
>> your mind already, and posted accordingly.
>
> I think most of us just assumed he was just trolling and were playing
> along for the fun of it.

What was troll-like about it? The OP made it clear he didn't like the
way Python made use of tabs, but he didn't want an argument about it or
to be persuaded to change his mind or change anyone else's.

He wanted to know if there was a simple syntax wrapper for it. That
seems reasonable enough.

(Actually *I* would quite like to know why languages don't have