allowing braces around suites

[Kjetil Torgrim Homme]

often when re-factoring code, I need to change the indent level of
some chunk of code. due to the lack of an end marker, my Emacs has to
use heuristics when re-indenting, and this will occasionally lead to
mistakes. of course this is really _my_ fault, not Emacs', but it's
annoying all the same.

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.

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. code which uses braces and is wrongly re-indented will
always cause a syntax error during compilation.

code could look like this:

def appraise_insurance(rental_cars):
{
assert isinstance(rental_cars, (list, tuple))

for car in rental_cars:
{
if car.make == "Lamborghini":
{
car.insurance = 1000.00
}
elif car.make == "Lada":
{
car.insurance = 50.00
}
else:
{
car.insurance = 100.00
}
}
logger.debug("Insurance values updated")
}

now, I don't suggest to write code like that, that has far too much
air between actual codelines. I'd only add the braces where there is
a risk re-indentation changing the meaning of the program, like this:

def appraise_insurance(rental_cars):
assert isinstance(rental_cars, (list, tuple))

for car in rental_cars:
{
if car.make == "Lamborghini":
car.insurance = 1000.00
elif car.make == "Lada":
car.insurance = 50.00
else:
car.insurance = 100.00
}
logger.debug("Insurance values updated")

the single pair of braces is enough. there is now no risk of Emacs
including the debug line into the else branch unnoticed.

the patch to implement this is very simple and restricted to the
tokenizer. as it stands, it requires the braces to be placed as in
the above examples, you _can't_ write

if True: {
code
} else {
code
}

a single braces style improves readability and style consistency among
software projects. my patch does allow two styles, though: to reduce
line count you can put the else: on the same line as the closing
brace.

if True:
{
code
} else:
{
code
}

in both styles, the braces line up and IMHO this makes it easier to
identify where a medium sized block begins and ends.

there can be no code after an opening brace, but it's a good place to
put a comment, so in practice the number of added lines may not be so
large.
a small caveat: it breaks code which looks like this:

def test_varargs1(self):
"""some text"""
{}.has_key(0)

this function is taken from Lib/test/test_call.py, but the doc string
was added to make my patched Python reject it with a syntax error.
the problem is that a brace at the same indent level as the line above
will always mark the beginning of a new suite. I don't think such
code is widespread, but would be interested in hearing contrary
experiences. one fix for this issue is to have the parser tell the
tokenizer whether "a suite may follow" when it asks for the next
token, but I haven't persued writing such a patch.

a patch relative to Python 2.4a2 is available at

http://heim.ifi.uio.no/~kjetilho/hac...on-2.4a2.patch

what do you think? should I write a PEP?
--
Kjetil T.

[Michael Sparks]

Kjetil Torgrim Homme wrote:
...

what do you think? should I write a PEP?

It's more fun to ask python what it thinks:

michaels@pc474:~/Documents> python
Python 2.3.3 (#1, Apr 6 2004, 01:47:39)
[GCC 3.3.3 (SuSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

from __future__ import braces File "<stdin>", line 1
SyntaxError: not a chance

^^^^^^^^^^^^

I suspect you might have a hard time getting anywhere with this ;)

Regards,
Michael.
--
Mi************@rd.bbc.co.uk
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP

This message (and any attachments) may contain personal views
which are not the views of the BBC unless specifically stated.

[Kjetil Torgrim Homme]

[Michael Sparks]:

Kjetil Torgrim Homme wrote:

> what do you think? should I write a PEP?

I suspect you might have a hard time getting anywhere with this ;)

well, in the previous discussions I've read, the proponents of braces
want them as an alternative to strict indentation. that's not the
case here, so the code is still kept pythonic, IMO.

--
Kjetil T.

[Andrew Durdin]

On Fri, 27 Aug 2004 12:40:02 +0100, Michael Sparks
<mi******@rd.bbc.co.uk> wrote:

Kjetil Torgrim Homme wrote:
...

what do you think? should I write a PEP?

The whole topic of explicit[*] end-of-block markers was brought up and
discussed at great length in May 1994:

http://groups.google.com/groups?hl=e...8%40vicorp.com

(I was looking at the old archives of c.l.py to try and find info on
the origins of triple-quoted strings and docstrings, both of which
were born around April 1994)

Regardless of history, it looks to me like your problem could be
better solved by modifying your emacs mode to consider whitespace more
correctly -- AFAICT there is no reason why it should ever pick up the
logging line in your example and indent it to the same level as the
else: block.

[Kjetil Torgrim Homme]

[Andrew Durdin]:

The whole topic of explicit[*] end-of-block markers was brought up
and discussed at great length in May 1994:

http://groups.google.com/groups?thre...8%40vicorp.com
thank you for the reference! I'm happy to see that Guido wasn't
strictly opposed to such a feature 10 years ago.
Regardless of history, it looks to me like your problem could be
better solved by modifying your emacs mode to consider whitespace
more correctly -- AFAICT there is no reason why it should ever
pick up the logging line in your example and indent it to the same
level as the else: block.

how can Emacs tell? if I press TAB and thus ask Emacs to re-indent
the line, that's what it will do. arguably, the correct fix is to
disable the "clever" re-indentation code of Emacs since it's too easy
to fool it, but this makes coding more awkward in other cases. it
also doesn't solve cut-n-paste errors.
--
Kjetil T.

[Wolfram Kraus]

Kjetil Torgrim Homme wrote:
[...]

Regardless of history, it looks to me like your problem could be
better solved by modifying your emacs mode to consider whitespace
more correctly -- AFAICT there is no reason why it should ever
pick up the logging line in your example and indent it to the same
level as the else: block.

how can Emacs tell? if I press TAB and thus ask Emacs to re-indent
the line, that's what it will do. arguably, the correct fix is to
disable the "clever" re-indentation code of Emacs since it's too easy
to fool it, but this makes coding more awkward in other cases. it
also doesn't solve cut-n-paste errors.

You can use C-c < or C-c > in Emacs to (de-)indent regions.

Wolfram

[Anthony Baxter]

On Fri, 27 Aug 2004 14:55:26 +0200, Kjetil Torgrim Homme

thank you for the reference! I'm happy to see that Guido wasn't
strictly opposed to such a feature 10 years ago.

Regardless of what he thought back then, I think I can say with
absolutely no fear of contradiction that there is no chance in hell of
braces appearing in Python... ever.

If your tool gets something wrong, fix the tool, don't try and change
the language, just for the convenience of a broken tool.

[Isaac To]

>>>>> "Kjetil" == Kjetil Torgrim Homme <kj******@yksi.ifi.uio.no> writes:

Kjetil> how can Emacs tell? if I press TAB and thus ask Emacs to
Kjetil> re-indent the line, that's what it will do.

If the aim is simply to do a local change that is sufficient to deal
with the problem just in your computer, then the simplest answer might
be to use "pass": if your code contains

if t1 == t2:
t1 = t3
else:
t2 = t3
pass
t = t2

and you tab at the last line, Emacs won't try to indent the t=t2 line
further to after the pass line where it is impossible to execute.

If you want something that is done globally and everybody will use
it... not a chance.

Kjetil> arguably, the correct fix is to disable the "clever"
Kjetil> re-indentation code of Emacs since it's too easy to fool
Kjetil> it, but this makes coding more awkward in other cases.

The indent-region command of Emacs (M-C-\) is really disabled in
Python mode, I think it is done by nullifying the
indent-region-function. Anyway, reindent makes sense only when the
indentation does not constitute the meaning of a program and thus the
editor can freely change it. If indentation does mean something, it
doesn't make sense at all.

Kjetil> it also doesn't solve cut-n-paste errors.

Use C-c > and C-c < might work for you.

Regards,
Isaac.

[Aaron Bingham]

Wolfram Kraus wrote:

Kjetil Torgrim Homme wrote:
[...]

how can Emacs tell? if I press TAB and thus ask Emacs to re-indent
the line, that's what it will do. arguably, the correct fix is to
disable the "clever" re-indentation code of Emacs since it's too easy
to fool it, but this makes coding more awkward in other cases. it
also doesn't solve cut-n-paste errors.

You can use C-c < or C-c > in Emacs to (de-)indent regions.

Or C-M-\ to re-indent the region "correctly" with respect to its
context. This works far more reliably the using TAB to re-indent single
lines.

--
--------------------------------------------------------------------
Aaron Bingham
Application Developer
Cenix BioScience GmbH
--------------------------------------------------------------------

[Kjetil Torgrim Homme]

[Isaac To]:

If the aim is simply to do a local change that is sufficient to
deal with the problem just in your computer, then the simplest
answer might be to use "pass": if your code contains

if t1 == t2:
t1 = t3
else:
t2 = t3
pass
t = t2

and you tab at the last line, Emacs won't try to indent the t=t2
line further to after the pass line where it is impossible to
execute.
interesting idea, but Python won't discover inconsistencies. if only
an Emacs solution is sought, a "# end" convention is preferable since
it's more explicit. an explicit convention that Python recognises
would be even better.
If you want something that is done globally and everybody will use
it... not a chance.

I don't expect everybody to use it. miscellaneous projects where the
developers are comfortable with it might want to add it to their
coding standards.
--
Kjetil T.

[Isaac To]

>>>>> "Kjetil" == Kjetil Torgrim Homme <kj******@yksi.ifi.uio.no> writes:

and you tab at the last line, Emacs won't try to indent the
t=t2 line further to after the pass line where it is
impossible to execute.

^^^^^^^^^^^^^^^^^^^^^

At the second glance this statement is false. If you have a statement
after "pass" it actually will execute after the pass statement which
does nothing. So this is purely a convention of Emacs, making use of
a pattern that is never useful in programs anyway. (If you have such
pass statement and the next statement is in the same suite, you simply
would delete the pass statement.) The "return" statement also has the
same effect.

Kjetil> interesting idea, but Python won't discover
Kjetil> inconsistencies.

It's a Emacs convention, so it is of course the burden of Emacs to
detect inconsistency, i.e., a change of indentation is not indicated
by a "pass", "return", or a statement ending with ":" and perhaps some
comments after it. I imagine that it would be a very simple regular
expression to write if you really want to do it.

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.

Regards,
Isaac.

[Kjetil Torgrim Homme]

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

[Thomas Heller]

Aaron Bingham <bi*****@cenix-bioscience.com> writes:

Wolfram Kraus wrote:

Kjetil Torgrim Homme wrote:
[...]

how can Emacs tell? if I press TAB and thus ask Emacs to re-indent
the line, that's what it will do. arguably, the correct fix is to
disable the "clever" re-indentation code of Emacs since it's too easy
to fool it, but this makes coding more awkward in other cases. it
also doesn't solve cut-n-paste errors.

You can use C-c < or C-c > in Emacs to (de-)indent regions.

Or C-M-\ to re-indent the region "correctly" with respect to its
context. This works far more reliably the using TAB to re-indent
single lines.

How do you enter that on a german keyboard?

Thomas

[Jacek Generowicz]

Kjetil Torgrim Homme <kj******@yksi.ifi.uio.no> writes:

often when re-factoring code, I need to change the indent level of
some chunk of code. due to the lack of an end marker, my Emacs has
to use heuristics when re-indenting,
You've lost me here.

When you want to change the indent level of some chunk of Python code
in Emacs, you highlight the chunk of code and hit C-c > or C-c <.

I don't see any scope for heuristics here.
def appraise_insurance(rental_cars):
assert isinstance(rental_cars, (list, tuple))

for car in rental_cars:
{
if car.make == "Lamborghini":
car.insurance = 1000.00
elif car.make == "Lada":
car.insurance = 50.00
else:
car.insurance = 100.00
}
logger.debug("Insurance values updated") the single pair of braces is enough. there is now no risk of Emacs
including the debug line into the else branch unnoticed.
How about

for car in rental_cars:
if car.make == "Lamborghini":
car.insurance = 1000.00
elif car.make == "Lada":
car.insurance = 50.00
else:
car.insurance = 100.00
pass
pass
logger.debug("Insurance values updated")

?

Hmm ... not pretty, but at least it doesn't PERLize the language.
what do you think? should I write a PEP?

Yes please write a PEP. It will be formally rejected, thereby forming
an excellent reference to which we might direct people who come up
with similar ideas.

[Wolfram Kraus]

Thomas Heller wrote:

Aaron Bingham <bi*****@cenix-bioscience.com> writes:

[...]

Or C-M-\ to re-indent the region "correctly" with respect to its
context. This works far more reliably the using TAB to re-indent
single lines.

How do you enter that on a german keyboard?

Thomas

CTRL-ALT-ALTGR-ß

Wolfram

[Marius Bernklev]

Jacek Generowicz <ja**************@cern.ch> writes:

Hmm ... not pretty, but at least it doesn't PERLize the language.

True. @pie decorators fill up three years' worth.
--
Marius Bernklev

[Ville Vainio]

>>>>> "Kjetil" == Kjetil Torgrim Homme <kj******@yksi.ifi.uio.no> writes:

Kjetil> what do you think? should I write a PEP?

No - you should see C:\Python23\Tools\Scripts\pindent.py (if you are
on windos) or snatch the file from the source distribution.

--
Ville Vainio http://tinyurl.com/2prnb

[Thomas Heller]

> [...]

Or C-M-\ to re-indent the region "correctly" with respect to its
context. This works far more reliably the using TAB to re-indent
single lines.

How do you enter that on a german keyboard?

CTRL-ALT-ALTGR-ß

Not for me - it only beeps. Well, maybe because I'm using XEmacs on win2k.

Do you mean the function py-indent-region? Apparently this is bound to
C-c tab or C-c C-i.

Thomas

[Antoon Pardon]

Op 2004-08-27, Anthony Baxter schreef <an***********@gmail.com>:

On Fri, 27 Aug 2004 14:55:26 +0200, Kjetil Torgrim Homme

thank you for the reference! I'm happy to see that Guido wasn't
strictly opposed to such a feature 10 years ago.

Regardless of what he thought back then, I think I can say with
absolutely no fear of contradiction that there is no chance in hell of
braces appearing in Python... ever.

If your tool gets something wrong, fix the tool, don't try and change
the language, just for the convenience of a broken tool.

Well people do make mistakes and it would be helpfull if the language
provides some feautures to help in repairing those mistakes.

It has happend that through some faulty manipulations code that
came after a loop became indented at the same level as the loop.
Because python has no end-markers that meant it wasn't obvious
to spot where the loop was supposed to stop and from where I
had to start deindenting the code.

Now of course I can remedy this situation by using comments
like #end, #if etc. That will make it obvious to correct such
mistakes. However I think one could argue that providing such
endmarkers helps readability as much as indenting code does
and since that is the principal argument for the enforced
indentation, one could consider the case for endmarkers.

--
Antoon Pardon

[Kjetil Torgrim Homme]

[Jacek Generowicz]:

How about

for car in rental_cars:
if car.make == "Lamborghini":
car.insurance = 1000.00
elif car.make == "Lada":
car.insurance = 50.00
else:
car.insurance = 100.00
pass
pass
logger.debug("Insurance values updated")

?

Hmm ... not pretty, but at least it doesn't PERLize the language.

"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.
--
Kjetil T.

[Andrew Koenig]

"Kjetil Torgrim Homme" <kj******@yksi.ifi.uio.no> wrote in message
news:1r************@rovereto.ifi.uio.no...

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

--
Dale Strickland-Clark
Riverhall Systems Ltd, www.riverhall.co.uk

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

[Anthony Baxter]

On Fri, 27 Aug 2004 13:29:58 +0200, Kjetil Torgrim Homme
<kj******@yksi.ifi.uio.no> wrote:

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]

Kjetil Torgrim Homme <kj******@yksi.ifi.uio.no> wrote:

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]

Kjetil Torgrim Homme wrote:

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

"Kjetil Torgrim Homme" <kj******@yksi.ifi.uio.no> wrote in message
news:1r************@rovereto.ifi.uio.no...

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

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]

Andrew Koenig wrote:

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

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

[Kjetil Torgrim Homme]

Anthony Baxter wrote:

Kjetil Torgrim Homme wrote:

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.

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!
--
Kjetil T.

[Isaac To]

>>>>> "Kjetil" == Kjetil Torgrim Homme <kj******@yksi.ifi.uio.no> writes:

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" == Kjetil Torgrim Homme <kj******@yksi.ifi.uio.no> writes:

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.

[Jeff Shannon]

Kjetil Torgrim Homme wrote:

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

[Isaac To]

>>>>> "Kjetil" == Kjetil Torgrim Homme <kj******@yksi.ifi.uio.no> writes:

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.

[Paul McGuire]

"Kjetil Torgrim Homme" <kj******@ifi.uio.no> wrote in message
news:ma**************************************@pyth on.org...

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]

On Sat, 28 Aug 2004 02:07:43 GMT, Paul McGuire
<pt***@austin.rr._bogus_.com> wrote:

"Kjetil Torgrim Homme" <kj******@ifi.uio.no> wrote in message
news:ma**************************************@pyth on.org...

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.

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]

Kjetil Torgrim Homme wrote:

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

--
"Codito ergo sum"
Roel Schroeven

[Kjetil Torgrim Homme]

[Roel Schroeven]:

Kjetil Torgrim Homme wrote:

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

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

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

[Reinhold Birkenfeld]

Isaac To wrote:

>> "Kjetil" == Kjetil Torgrim Homme <kj******@yksi.ifi.uio.no> writes:

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.

Why would you call (2,) syntax a hack?

If you like, you can call tuple([2]), but I would consider _this_ an
ugly solution or a "hack".

Reinhold

--
[Windows ist wie] die Bahn: Man muss sich um nichts kuemmern, zahlt fuer
jede Kleinigkeit einen Aufpreis, der Service ist mies, Fremde koennen
jederzeit einsteigen, es ist unflexibel und zu allen anderen Verkehrs-
mitteln inkompatibel. -- Florian Diesch in dcoulm

[Alex Martelli]

Kjetil Torgrim Homme <kj******@yksi.ifi.uio.no> wrote:
...

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 ... my hope is that my solution can be ignored by those who don't need it,
and used by those who like it.

Unfortunately, if you make it optional, "external code will naturally
not comply" still applies. Either for your solution or for any of those
you list above, you need in any case a simple tool that will take
noncomplying (but otherwise assumed to be correct) code and insert the
terminators. Given that you need this tool, why not also have the tool
able to CHECK that a module complies? This way you don't need to change
Python to give a syntax error for non compliance.

Best of all, the hypothetical tool almost exists, you have it:

....whereveryoukeeppython.../Tools/scripts/pindent.py

It uses the '# end if' style, but you could alter that in your copy.
The 'almost' is because I don't think it has the 'just check and tell me
if something wrong' functionality -- it's just able to insert or remove
the terminators into/from an otherwise correct source, and to fix up
indents in a source file which has proper terminators -- from the
latter, a switch to have it just check shouldn't be hard to add (exit
with error indicator if any fixup would be needed, say).
Once you have scripts that do whatever checking you wish and have a
uniform specified way to signal errors, you could think of a general and
truly useful addition to Python: a commandline switch (ideally settable
as a sys. attribute at runtime too) that makes it run checking scripts
automatically as part of the compilation process when it imports any
source (.py) file. This would put pay to the problem common to all
"offline" checkers -- "the checker would have diagnosed the problem but
I did not run it". You could run pindent, pychecker, unit tests,
_whatever_ -- possibly at the price of slowing down imports of newly
edited sources, but that depends on how thoroughly you want to check,
only. What we need, I think, are good conventions to determine what to
run on the source (before compilation), what on the bytecode (right
after compilation, or possibly even, every time, even when importing a
bytecode .pyc file), how a checker lets Python know about problems, how
Python in turn diagnoses them to the user.

Hmmm -- I'm thinking that the existing import hooks might be enough to
let one prototype this "automatic checking" functionality, not quite as
smoothly as a fully architected system maybe, but enough to get some
early adopters, shake out teething problems, build a constituency to
lobby for smoother integration in a future Python version...
Alex

[Roel Schroeven]

Kjetil Torgrim Homme wrote:

[Roel Schroeven]:

Kjetil Torgrim Homme wrote:

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

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.

I immediately saw what the code does; at first I didn't know it was the
bug you were referring to since I don't know what the code is supposed
to do. Then I read 'only students have their data updated' as
description of the bug, and only then I knew that the commit was
incorrectly indented.
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.

In that case, I agree it can be harder. But IMO it gets harder with
increasing code complexity, whether braces are used or not. I haven't
yet seen very complex python programs, but I have seen C and C++ code
with multiple nesting levels, and let me assure that it can sometimes be
very difficult to spot errors.

--
"Codito ergo sum"
Roel Schroeven

[Kjetil Torgrim Homme]

[Roel Schroeven]:

Kjetil Torgrim Homme wrote:

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

In that case, I agree it can be harder. But IMO it gets harder
with increasing code complexity, whether braces are used or not. I
haven't yet seen very complex python programs, but I have seen C
and C++ code with multiple nesting levels, and let me assure that
it can sometimes be very difficult to spot errors.

indeed, C or C++ is no better in this respect, quite the opposite IMO.
Paul McGuire illustrated the corresponding problem in C:

db->update_name(person);

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

I think it's harder to spot the bug here than in my Python example.
this doesn't mean Python can't be improved further :-)
--
Kjetil T.

[Isaac To]

>>>>> "Kjetil" == Kjetil Torgrim Homme <kj******@yksi.ifi.uio.no> writes:

Kjetil> I think it's harder to spot the bug here than in my Python
Kjetil> example. this doesn't mean Python can't be improved
Kjetil> further :-) -- Kjetil T.

I don't think your proposal to throw { and } into the code will solve
the problem and make it easier, though.

Regards,
Isaac.

[Grant Edwards]

On 2004-08-28, Reinhold Birkenfeld <re************************@wolke7.net> wrote:

Isaac To wrote:

>>> "Kjetil" == Kjetil Torgrim Homme <kj******@yksi.ifi.uio.no> writes:
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.

Why would you call (2,) syntax a hack?

Because so many people at first think that parens construct
tuples the way square-brackets and curly-brackets construct
lists. When in reality it's commas that construct tuples, but
only in certain contexts because commas are used for about
three other purposes as well.
If you like, you can call tuple([2]), but I would consider _this_ an
ugly solution or a "hack".

I would call it the former.

IMO, the only non-ugly, non-hack solution would be to have
another set of delimters that are used as tuple-constructors so
tha the syntax for a literal tuple, a literal list, and a
literal dictionary are consistent.

--
Grant Edwards grante Yow! AIEEEEE! I am having
at an UNDULATING EXPERIENCE!
visi.com

[Grant Edwards]

On 2004-08-28, Grant Edwards <gr****@visi.com> wrote:

Why would you call (2,) syntax a hack?

Because so many people at first think that parens construct
tuples the way square-brackets and curly-brackets construct
lists.

Um, that should have finished with "and curly-braces construct
dictionaries."

--
Grant Edwards grante Yow! Th' MIND is the Pizza
at Palace of th' SOUL
visi.com

[Roy Smith]

In article <41***********************@newsreader.visi.com>,
Grant Edwards <gr****@visi.com> wrote:

Because so many people at first think that parens construct
tuples the way square-brackets and curly-brackets construct
lists. When in reality it's commas that construct tuples, but
only in certain contexts because commas are used for about
three other purposes as well.
[...]
IMO, the only non-ugly, non-hack solution would be to have
another set of delimters that are used as tuple-constructors so
that the syntax for a literal tuple, a literal list, and a
literal dictionary are consistent.

I agree. It's even uglier that "," doesn't form a zero-length tuple.
Thus you get:

tuple0 = ()
tuple1 = 1,

So, is it parens that form tuples, or commas? I guess There's More Than
One Way To Do It :-)

My personal choice would have been angle brackets, i.e. <1, 2, 3>.
Then, <1> would have been a length-1 tuple with no ambiguity.

tuple0 = <>
tuple1 = <1>
tuple2 = <1, 2>

But it's way too late for that now. Maybe in P3K?

[Alex Martelli]

Grant Edwards <gr****@visi.com> wrote:
...

IMO, the only non-ugly, non-hack solution would be to have
another set of delimters that are used as tuple-constructors so
tha the syntax for a literal tuple, a literal list, and a
literal dictionary are consistent.

I think that a hypothetical greenfield-designed language similar to
Python might do without literal tuples, lists, and dictionaries, just
like Python today does without literal sets (in 2.4 where they're a
built-in type). It would make some constructs more verbose,
specifically using words instead of punctuation, but I think that,
overall, that is reasonably Pythonic.

list(a, b, c) instead of [a, b, c] would not be horribly heavy syntax, I
think. You can already use list() instead of [] -- just as dict()
instead of {} -- and I think sometimes that's more readable, even having
both choices. tuple would work like list. dict isn't quite so obvious,
except where the keys are constant strings that happen to be identifiers
in which case, even today, dict(a=1,b=2,c=3) is fine. But I'm sure fine
solutions could be identified, as, also, for the issue of how to
differentiate from list(x) meaning [x] and list(x) meaning the same as
[foo for foo in x] -- for example list(*x) would also mean the latter,
so maybe that's the solution for this.

I think 'commas makes tuples when the commas don't mean anything else'
should stay, though, because somedict[x, y] or a,b=b,a depend on that,
and I find them just too sweet to lose!-)

This of course is all pretty hypothetical, just like the idea of
introducing a new set of delimiters -- won't happen in Python, not even
in 3.0. Just musing about some details of language design.
Alex

[Isaac To]

>>>>> "Alex" == Alex Martelli <al*****@yahoo.com> writes:

Alex> list(a, b, c) instead of [a, b, c] would not be horribly
Alex> heavy syntax, I think.

On the other hand, [b*b for b in c] is too sweet to lose as well. :)

Regards,
Isaac.