On Wed, Jan 4, 2012 at 00:30, Stephen J. Turnbull step...@xemacs.org wrote:
Benjamin Peterson writes:
My goodness, I was trying to make a ridiculous-sounding proposition.
In this kind of discussion, that's in the same class as be careful
what you wish for -- because you might just get it.
He keeps leaving them out, I occasionally tell him they should always
be included (most recently this came up when we gave conflicting
advice to a patch contributor). He says what he's doing is OK, because
he doesn't consider the example in PEP 7 as explicitly disallowing it,
I think it's a
FWIW I'm against forcing braces to be used. Readability is the highest
concern, and this should be at the discretion of the contributor. A
code formatting tool, or compiler extension is the only proper handle
this, and neither are in use or available.
On Tue, Jan 3, 2012 at 7:44 PM, Martin v.
Matt Joiner writes:
Readability is the highest concern, and this should be at the
discretion of the contributor.
That's quite backwards. Readability is community property, and has
as much, if not more, to do with common convention as with some
absolute metric. The contributor's discretion
Stephen J. Turnbull wrote:
Matt Joiner writes:
Readability is the highest concern, and this should be at the
discretion of the contributor.
That's quite backwards. Readability is community property, and has
as much, if not more, to do with common convention as with some
absolute metric.
Stephen J. Turnbull step...@xemacs.org writes:
Matt Joiner writes:
Readability is the highest concern, and this should be at the
discretion of the contributor.
That's quite backwards. Readability is community property, and has
as much, if not more, to do with common convention as with
Readability also includes more than just the source code; as has already
been stated:
if(cond) {
stmt1;
+ stmt2;
}
vs.
-if(cond)
+if(cond) {
stmt1;
+ stmt2;
+}
I find the diff version that already had braces in place much more
readable.
Is it really *much* more
Ethan Furman ethan at stoneleaf.us writes:
Readability also includes more than just the source code; as has already
been stated:
if(cond) {
stmt1;
+ stmt2;
}
vs.
-if(cond)
+if(cond) {
stmt1;
+ stmt2;
+}
I find the diff version that already had braces in place
Benjamin Peterson writes:
Ethan Furman ethan at stoneleaf.us writes:
Readability also includes more than just the source code; as has already
been stated:
[diffs elided]
I find the diff version that already had braces in place much more
readable.
There are much larger
2012/1/3 Stephen J. Turnbull step...@xemacs.org:
Benjamin Peterson writes:
Ethan Furman ethan at stoneleaf.us writes:
Readability also includes more than just the source code; as has already
been stated:
[diffs elided]
I find the diff version that already had braces in place
Benjamin Peterson writes:
My goodness, I was trying to make a ridiculous-sounding proposition.
In this kind of discussion, that's in the same class as be careful
what you wish for -- because you might just get it.
___
Python-Dev mailing list
On Mon, Jan 2, 2012 at 4:22 PM, Ron Adam ron3...@gmail.com wrote:
The problem is only when an additional statement is added to the last
block, not the preceding ones, as the compiler will complain about
those. So I don't know how the 4 line example without braces is any
worse than a 2 line if
On Jan 1, 2012, at 8:44 PM, Nick Coghlan wrote:
I've been having an occasional argument with Benjamin regarding braces
in 4-line if statements:
if (cond)
statement;
else
statement;
vs.
if (cond) {
statement;
} else {
statement;
}
Really? Do we need to have a
On Mon, Jan 2, 2012 at 6:47 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
Really? Do we need to have a brace war?
People have different preferences.
The standard library includes some of both styles
depending on what the maintainer thought was cleanest to their eyes in a
given
On Mon, 2 Jan 2012 14:44:49 +1000
Nick Coghlan ncogh...@gmail.com wrote:
I've been having an occasional argument with Benjamin regarding braces
in 4-line if statements:
if (cond)
statement;
else
statement;
vs.
if (cond) {
statement;
} else {
statement;
}
Antoine Pitrou wrote:
I don't like having the else on the same line as the closing brace,
and prefer:
if (cond) {
statement;
}
else {
statement;
}
And this is how it's written in PEP-7. It seems to me that PEP-7
doesn't require braces. But it explicitly forbids
On 1/1/2012 11:44 PM, Nick Coghlan wrote:
I've been having an occasional argument with Benjamin regarding braces
in 4-line if statements:
if (cond)
statement;
else
statement;
vs.
if (cond) {
statement;
} else {
statement;
}
He keeps leaving them out, I
2012/1/1 Nick Coghlan ncogh...@gmail.com:
I've been having an occasional argument with Benjamin regarding braces
in 4-line if statements:
Python's C code has been dropping braces long before I ever arrived.
See this beautiful example in dictobject.c, for example:
if (numfree
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/02/2012 01:02 AM, Nick Coghlan wrote:
On Mon, Jan 2, 2012 at 3:04 PM, Scott Dial
scott+python-...@scottdial.com wrote:
On 1/1/2012 11:44 PM, Nick Coghlan wrote:
I think it's a recipe for future maintenance hassles when someone
adds a
2012/1/1 Nick Coghlan ncogh...@gmail.com:
if (cond) {
statement;
} else {
statement;
}
I might add that assuming you have braces, PEP 7 would want you to format it as
if (cond) {
statement;
}
else {
more_stuff;
}
--
Regards,
Benjamin
On 01/02/2012 12:47 AM, Raymond Hettinger wrote:
Really? Do we need to have a brace war?
People have different preferences.
The standard library includes some of both styles
depending on what the maintainer thought was cleanest to their eyes in a given
context.
I'm with Raymond. Code should
On Mon, Jan 2, 2012 at 1:50 PM, Larry Hastings la...@hastings.org wrote:
On 01/02/2012 12:47 AM, Raymond Hettinger wrote:
Really? Do we need to have a brace war?
People have different preferences.
The standard library includes some of both styles
depending on what the maintainer thought
On 3 January 2012 08:50, Larry Hastings la...@hastings.org wrote:
On 01/02/2012 12:47 AM, Raymond Hettinger wrote:
Really? Do we need to have a brace war?
People have different preferences.
The standard library includes some of both styles
depending on what the maintainer thought was
On Jan 2, 2012, at 12:31 PM, Benjamin Peterson wrote:
I might add that assuming you have braces, PEP 7 would want you to format it
as
if (cond) {
statement;
}
else {
more_stuff;
}
Running ``grep -B1 else Objects/*c`` shows that we've happily lived with a
mixture of styles
On Jan 2, 2012, at 2:09 PM, Tim Delaney wrote:
I'd also point out that if you're expecting braces, not having them can make
the code less readable.
If a programmer's mind explodes when they look at the simple and beautiful
examples in KR's The C Programming Language, then they've got
On 1/2/2012 5:32 PM, Raymond Hettinger wrote:
Running ``grep -B1 else Objects/*c`` shows that we've happily lived
with a mixture of styles for a very long time.
ISTM, our committers have had good instincts about when braces add
clarity and when they add clutter.
If Nick pushes through an
On Tue, Jan 3, 2012 at 12:54 AM, Benjamin Peterson benja...@python.org wrote:
I think it's fine Nick raised this. PEP 7 is not very explicit about
braces at all.
I actually discovered in this thread that I've been misreading PEP 7
for going on 7 years now - I thought the brace usage example
On Tue, Jan 3, 2012 at 8:32 AM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
Running ``grep -B1 else Objects/*c`` shows that we've happily lived with a
mixture of styles for a very long time.
ISTM, our committers have had good instincts about when braces add clarity
and when they add
On Jan 2, 2012, at 4:27 PM, Nick Coghlan wrote:
With my perception of the status quo corrected, I can stop worrying
about preserving a non-existent consistency.
+1 QOTD
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
On 3 January 2012 09:55, Raymond Hettinger raymond.hettin...@gmail.comwrote:
On Jan 2, 2012, at 2:09 PM, Tim Delaney wrote:
I'd also point out that if you're expecting braces, not having them can
make the code less readable.
If a programmer's mind explodes when they look at the simple and
On Mon, Jan 2, 2012 at 4:27 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Jan 3, 2012 at 8:32 AM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
Running ``grep -B1 else Objects/*c`` shows that we've happily lived
with a
mixture of styles for a very long time.
ISTM, our
On Jan 02, 2012, at 02:08 PM, Guido van Rossum wrote:
The irony is that style guides exist to *avoid* debates like this. Yes, the
choices are arbitrary. Yes, tastes differ. Yes, there are exceptions to the
rules. But still, once a style rule has been set, the idea is to stop
debating and just
I've been having an occasional argument with Benjamin regarding braces
in 4-line if statements:
if (cond)
statement;
else
statement;
vs.
if (cond) {
statement;
} else {
statement;
}
He keeps leaving them out, I occasionally tell him they should always
be included
Nick Coghlan ncogh...@gmail.com writes:
He keeps leaving [braces] out [when the block is a single statement],
I occasionally tell him they should always be included (most recently
this came up when we gave conflicting advice to a patch contributor).
As someone who has maintained his fair
On 1/1/2012 11:44 PM, Nick Coghlan wrote:
I think it's a recipe for future maintenance hassles when someone adds
a second statement to one of the clauses but doesn't add the braces.
(The only time I consider it reasonable to leave out the braces is for
one liner if statements, where there's no
On Mon, Jan 2, 2012 at 3:04 PM, Scott Dial
scott+python-...@scottdial.com wrote:
On 1/1/2012 11:44 PM, Nick Coghlan wrote:
I think it's a recipe for future maintenance hassles when someone adds
a second statement to one of the clauses but doesn't add the braces.
(The only time I consider it
On Mon, 2012-01-02 at 14:44 +1000, Nick Coghlan wrote:
I've been having an occasional argument with Benjamin regarding braces
in 4-line if statements:
if (cond)
statement;
else
statement;
vs.
if (cond) {
statement;
} else {
statement;
}
He keeps
37 matches
Mail list logo
