allowing braces around suites

[Andrew Koenig]

my suggestion is to allow braces to mark the suites. Python is still
strictly enforcing indentation, in fact, in some ways it's stricter
then before.

The following code is legal today:

def foo(x):
print x
x = 3
if x == 3:
{
foo(x) : 42
}

Are you proposing to change the meaning of this code?

 

[Dale Strickland-Clak]

what do you think? should I write a PEP?

No. You should use Vim.

There's some nice macros for Python. Works lovely.

 

[Kjetil Torgrim Homme]

[Andrew Koenig]:

[Kjetil Torgrim Homme]:

my suggestion is to allow braces to mark the suites. Python is
still strictly enforcing indentation, in fact, in some ways it's
stricter then before.

The following code is legal today:

def foo(x):
print x
x = 3
if x == 3:
{
foo(x) : 42
}

Are you proposing to change the meaning of this code?

no, this code still works with my patch. the opening brace must be at
the same level as the preceding statement. this is not a problem,
since the insides of a literal dict can't be a valid Python expression
and vice versa, so you'll get a syntax error even if the misplaced
opening brace is mistakenly taken as the beginning of a dict by the
Python parser.

my current patch does have a problem as stated in my original message,
but this is really just a proof-of-concept. a patch with no backwards
compatibility problems can be prepared if there is interest.

 

[Anthony Baxter]

what do you think? should I write a PEP?

I've changed my mind. You should indeed write a PEP. I strongly
suggest you adopt the spirit of PEP-666 in doing this, as a PEP on
braces will get the same response. I'd even suggest PEP 667 (The
Neighbour of the Beast) as the PEP number.

Think of it as a public service - you can stop this idea coming up again.

Anthony

 

[Martin DeMello]

a colleague uses #fi, #yrt etc. to mark the end of blocks, but I don't
find this satisfactory since neither Python nor Emacs has any
knowledge of what the magic comment means.

The minimalist change would be to add support for #fi etc in emacs's
python mode, or perhaps support for #{ and #}

martin

 

[Jeff Shannon]

"pass" is a no-op, and should only be used when a suite is required,
but the suite should do nothing. you're proposing a convention saying

''if "pass" appears in a suite which also contains other
expressions, the "pass" signals the end of the suite''

that's a hack, and IMHO not worthy of a Python program. not even Perl
has anything like that, AFAIK.

The irony of these being said in defense of adding braces (even optional
ones) to Python is truly awe-inspiring.

Jeff Shannon
Technician/Programmer
Credit International

 

[Paul McGuire]

[Isaac To]:

When Python is concerned and Emacs is not, Python only sees there
is indentation, and only indentation, to define the suites. And
it is also what people will perceive when they stare at the code.
There is nothing to be inconsistent with it.

how long do you have to stare before spotting the bug?

db.update_name(person)
if is_student(person):
db.update_courses(person)
db.commit()

only students have their names updated. I wonder why.

real world examples have taken hours or days.

Here's a real-world C example, took us several weeks to track down - all the
programmer did was add some debugging code:

db->startTransaction();
db->update_name(person);

if ( is_student(person) )
log("update student %s", person->name );
db->update_courses(person);
-------------------------------------------page
break-----------------------------
db->commit();

Everybody has their courses updated whether students or not - why???

On the hardcopy, the update_courses() call was the last line on the page,
which made it that much harder to spot.

In fact, you can cite examples on this argument in either direction; it is
more than a little condescending to preach that "in the real world, my way
is the right way."

As far as Python goes, I think bracelessness is one of its defining
features; if some day braces were to get included in Python a la C or Java,
then it will cease to be Python.

-- Paul

 

[Leif K-Brooks]

The following code is legal today:

def foo(x):
print x
x = 3
if x == 3:
{
foo(x) : 42
}

Gyaah, you almost gave me a heart attack there. Nicely done.

 

[Kjetil Torgrim Homme]

[Jeff Shannon]:

The irony of [this] being said in defense of adding braces (even
optional ones) to Python is truly awe-inspiring.

please provide an argument rather than engage in ad hominem attacks.

 

[Kjetil Torgrim Homme]

[Paul McGuire]:

As far as Python goes, I think bracelessness is one of its
defining features; if some day braces were to get included in
Python a la C or Java, then it will cease to be Python.

I find this attitude a little defensive. Python has much more to
offer than just strict indentation. although it's probably the
feature you notice first, it's not enough to make Python a superior
language. after all, code in _any_ language written by a professional
will have strict indentation. so it's just syntax. the true
strengths of Python include its exception system, its class model and
instrospection. it's a very flexible language, you can construct
classes on the fly, implement your own private attributes etc. etc.
combine this with a comprehensive library for doing many common tasks,
and you'll see the strength of Python, a strength no other scripting
language offers.


(I have to point out that my braces suggestion is _not_ a la C or
Java, since strict indentation is still required for every line of
code in the program.)

 

[Kjetil Torgrim Homme]

I've changed my mind. You should indeed write a PEP. I strongly
suggest you adopt the spirit of PEP-666 in doing this, as a PEP on
braces will get the same response. I'd even suggest PEP 667 (The
Neighbour of the Beast) as the PEP number.

interesting, can I choose the number? (btw, I always thought 668 was
the neighbour of the beast.)

I'll write a PEP, but it will have to wait until next week. thank you
for your feedback!

 

[Isaac To]

Kjetil> how long do you have to stare before spotting the bug?

At the first instant when I look at the code, something like within 2
seconds.

Kjetil> db.update_name(person)
Kjetil> if is_student(person):
Kjetil> db.update_courses(person)
Kjetil> db.commit()

Kjetil> only students have their names updated. I wonder why.

Kjetil> real world examples have taken hours or days.

Perhaps because you don't know Python? Or because you are too
accustomed to writing C with broken indentation?

Regards,
Isaac.

 

[Isaac To]

Kjetil> that's a hack, and IMHO not worthy of a Python program.
Kjetil> not even Perl has anything like that, AFAIK.

Hm... hacks are not for Python?! We see every kind of hacks
everywhere in Python just like it is in Perl, like (2,) syntax, etc.
Some hacks are good, some are bad, and some are dependent on who is
looking at it.

I'm neutral on whether this particular hack is nice: if one get used
to "pass", one can train onself psychologically that it means "I've
got nothing else to do, pass to the upper level". It also doesn't
conflict with the previous use of pass.

I don't know how such logic works for others. At least, a pass
statement in a non-empty suite won't be used otherwise, so you can use
the convention to end suites safely---and in a way that need no change
at all in the Python interpreter. And you can use it *now*, since it
is implemented in the default Python mode of Emacs already.

Regards,
Isaac.

 

[Isaac To]

Kjetil> I find this attitude a little defensive. Python has much
Kjetil> more to offer than just strict indentation. although it's
Kjetil> probably the feature you notice first, it's not enough to
Kjetil> make Python a superior language.

For me, it is *the* feature that make it stands out from the scripting
crowd. There are other things nice in Python, but as long as there is
one big enough killing feature, people will use the language enough to
add others.

Kjetil> after all, code in _any_ language written by a
Kjetil> professional will have strict indentation. so it's just
Kjetil> syntax.

No. In all other languages, people deal with *two* ways to find which
statement is associated with an if/while/for/whatever statement and
which is not: by looking at the indentation, and by looking at the
braces. They normally look at the indentation, since it is the
quicker way. But when they find something wrong, they look at the
defining braces, sometimes deeply hidden in long expressions and
statements combined into one line. In Python, we have *one and only
one* way to find which statement is associated with an
if/while/for/whatever statement, and this is the quicker way that
people are used to. This single feature reduces the amount of bugs
that you would introduce when editing and modifying code. More
importantly, this single feature allows you to be much less stressed
when editing code.

Regards,
Isaac.

 

[Jeff Shannon]

[Jeff Shannon]:

The irony of [this] being said in defense of adding braces (even
optional ones) to Python is truly awe-inspiring.

please provide an argument rather than engage in ad hominem attacks.

One of the core concepts of Python philosophy is that of significant
indentation being more reliable than braces to indicate program
structure. The whole point of using indentation is that it's far more
natural for the human eye and mind to grasp; when one sees code in which
braces and indentation are used, but inconsistently, the natural
inclination is to follow the indentation rather than the braces. The
problem is that programmers have been trained for decades to use
delimiters, because that's the way languages were designed, because
earlier parsers had difficulty without them. But programmers have
*also* used indentation the whole time, because they needed it so that
*they* could understand their own code. The indentation is for the
programmers, the braces are for the compiler. Well, parser technology
has advanced to the point where hints like braces aren't needed, but
many programmers are so accustomed to having them that they keep looking
for excuses to keep them around.

There are endless examples, as I said, of how inconsistently indented C
code is far more confusing than braceless Python code. Now, admittedly,
your proposal here won't allow braces and indentation to be inconsistent
-- that'll throw a syntax error. But that means that you're encoding
the same information in two ways, which is a waste of effort and a waste
of mindspace. This isn't just providing more than one way to do it;
this is providing two ways to do it, and insisting that even if you use
the second you need to *also* use the first. That's like Amazon
providing an online order form, but still insisting that you phone in
your order before they'll deliver it.

Now, what do you gain by adding braces? The ability of tools to better
reindent code, supposedly. But I have to say, using block-indent and
block-dedent commands, I've never had a difficult time with maintaining
proper relative indentation of cut-and-pasted code blocks. I don't see
the problem you're trying to solve, I'm not aware of it being a
significant problem throughout Python's 10+ year history, and I honestly
doubt that your "solution" would provide much significant benefit.

So... you're proposing a significant change to the core language syntax,
which violates a number of Python core design principles, in order to
simplify the process for a tool to perform an infrequent task, which
it's quite capable of doing in a slightly different way already. And
yet, when someone else comments that the same lack-of-results can be
accomplished with a currently legal (though pointless) bit of
convention, you're worried that *they* are proposing something
non-Pythonic?

Note, also, that this is not an ad hominem attack. I say nothing about
you personally -- my comments are based entirely on the proposal and
argument that you put forward. I'm not calling you names or questioning
your morals; I'm merely pointing out that your complaint about Jacek's
response can be applied far more aptly to your own original post.

Jeff Shannon
Technician/Programmer
Credit International

(PS: I'm going to be away from the newsgroup for the weekend, so lack of
an immediate response on my part shouldn't be taken to construe anything
significant...)

 

[Paul McGuire]

I'll write a PEP, but it will have to wait until next week. thank you
for your feedback!

Kjetil -

I hate to see you waste the effort. If you look back through the archives,
you'll see that some form of "let's add braces to Python" proposal comes up
from the newcomer ranks every couple of months. Almost always, the proposal
is combined with some comments about "my editor can't handle indenting and
outdenting properly." Before you invest the time putting your case
together, I strongly suggest you review the comments and responses that have
already been put forth on this issue. And be sure that the Python community
does not need to be educated about what "real world" code looks like.

Please consider the possibility that bracelessness is one of the language
features you need to come to grips with as part of "embracing" a new
language. It will be great to see your energy and enthusiasm put forth to
learning about and participating in discussions of new Python language
features, instead of rehashing old news.

-- Paul

 

[Anthony Baxter]

Kjetil -

I hate to see you waste the effort.

I don't think it's a waste of effort. Once a PEP has been written and
rejected, future discussions on the subject can be pointed at the PEP.

 

[Roel Schroeven]

[Isaac To]:

When Python is concerned and Emacs is not, Python only sees there
is indentation, and only indentation, to define the suites. And
it is also what people will perceive when they stare at the code.
There is nothing to be inconsistent with it.

how long do you have to stare before spotting the bug?

Just the time needed to read the code.

db.update_name(person)
if is_student(person):
db.update_courses(person)
db.commit()

only students have their names updated. I wonder why.

No offense, but I wonder why you have a problem with this code. IMO the
indentation makes perfectly clear what's happening.

 

[Kjetil Torgrim Homme]

[Roel Schroeven]:

Just the time needed to read the code.


No offense, but I wonder why you have a problem with this
code. IMO the indentation makes perfectly clear what's happening.

I don't think it is appropriate that I dump thousands of lines of code
here to illustrate the problem

when I provide four lines of code and tell you there's a bug, of
course you can spot it immediately. when it's part of a large system,
it's a bit harder. also consider that the db.commit() originally was
correctly placed by the programmer, and the wrong indentation was
introduced later by an editing glitch.

 

[Kjetil Torgrim Homme]

[Jeff Shannon]:

Now, what do you gain by adding braces? The ability of tools to
better reindent code, supposedly.

no, the ability of having wrongly indented code throw syntax errors.
there are many workarounds for individual editors, but nothing to help
eliminate this error class altogether.

the many workarounds also lead to "more than one way to do it". the
code I read can be using "#fi", "# end if", "# }", "pass" or nothing.
sure, I can write a tool to enforce a single coding standard for my
project, but external code will naturally not comply. that's why I
think it would be good if Python decreed a single method of using both
belts and braces.

currently, I'm using the "nothing" style, and like it very much. my
motivation is that a member of our development group religuously
litters his code with "#fi" and "#done". rather than just tell him to
stop it, I thought I'd explore the avenue of a compromise, since I
myself would like to use braces in my code in some instances to
improve the visual cue in "deep" (4-5) indentation blocks. (this can
happen even if the function fits on the screen. splitting out the
core of it is in some cases awkward.)

But I have to say, using block-indent and block-dedent commands,
I've never had a difficult time with maintaining proper relative
indentation of cut-and-pasted code blocks.

I wouldn't say it's a frequent problem for me, it's happening me a
couple of times per year, and some of my colleagues report likewise.
but wasting perhaps a workday a year on such a silly issue is
annoying.

I don't see the problem you're trying to solve, I'm not aware of
it being a significant problem throughout Python's 10+ year
history, and I honestly doubt that your "solution" would provide
much significant benefit.

my hope is that my solution can be ignored by those who don't need it,
and used by those who like it.

Note, also, that this is not an ad hominem attack.

no, it was a long, well thought-out article. thank you.