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 1/2/2012 12:55 AM, Paul McMillan wrote:
Terry Reedy said:
I understood Alexander Klink and Julian Wälde, hash...@alech.de, as saying
that they consider that using a random non-zero start value is sufficient to
make the hash non-vulnerable.
I've been talking to them. They're happy to look
On Sun, 1 Jan 2012 21:55:52 -0800
Paul McMillan p...@mcmillan.ws wrote:
This is similar to the change proposed by Christian Heimes.
Most importantly, I moved the xor with r[x % len_r] down a line.
Before, it wasn't being applied to the last character.
Shouldn't it be r[i % len(r)] instead?
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
Christian Heimes writes:
Am 31.12.2011 13:03, schrieb Stephen J. Turnbull:
I don't know the implementation issues well enough to claim it is a
solution, but this hasn't been mentioned before AFAICS:
While the dictionary probe has to start with a hash for backward
compatibility
On Mon, 2 Jan 2012 14:44:49 +1000
Nick Coghlan ncogh...@gmail.com wrote:
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).
Oh, by the way, this is also why I avoid arguing too
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
On Mon, 02 Jan 2012 16:00:50 +0100
benjamin.peterson python-check...@python.org wrote:
http://hg.python.org/cpython/rev/d5cda62d0f8c
changeset: 74236:d5cda62d0f8c
user:Benjamin Peterson benja...@python.org
date:Mon Jan 02 09:00:30 2012 -0600
summary:
fix some possible
2012/1/2 Antoine Pitrou solip...@pitrou.net:
On Mon, 02 Jan 2012 16:00:50 +0100
benjamin.peterson python-check...@python.org wrote:
http://hg.python.org/cpython/rev/d5cda62d0f8c
changeset: 74236:d5cda62d0f8c
user: Benjamin Peterson benja...@python.org
date: Mon Jan 02
Am 02.01.2012 06:55, schrieb Paul McMillan:
I think Ruby uses FNV-1 with a salt, making it less vulnerable to
this. FNV is otherwise similar to our existing hash function.
For the record, cryptographically strong hash functions are in the
neighborhood of 400% slower than our existing hash
On 1/1/2012 12:28 PM, Christian Heimes wrote:
I understood Alexander Klink and Julian Wälde, hash...@alech.de, as
saying that they consider that using a random non-zero start value is
sufficient to make the hash non-vulnerable.
Sufficient against their current attack. But will it last? For
Am 01.01.2012 19:45, schrieb Terry Reedy:
On 1/1/2012 10:13 AM, Guido van Rossum wrote:
PS. Is the collision-generator used in the attack code open source?
As I posted before, Alexander Klink and Julian Wälde gave their project
email as hash...@alech.de. Since they indicated disappointment
On 01/02/2012 03:41 PM, Antoine Pitrou wrote:
On Mon, 2 Jan 2012 14:44:49 +1000
Nick Coghlan ncogh...@gmail.com wrote:
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).
On 01/02/2012 04:47 PM, Christian Heimes wrote:
Am 01.01.2012 19:45, schrieb Terry Reedy:
On 1/1/2012 10:13 AM, Guido van Rossum wrote:
PS. Is the collision-generator used in the attack code open source?
As I posted before, Alexander Klink and Julian Wälde gave their project
email as
On Mon, Jan 2, 2012 at 7:47 AM, Christian Heimes li...@cheimes.de wrote:
Am 01.01.2012 19:45, schrieb Terry Reedy:
On 1/1/2012 10:13 AM, Guido van Rossum wrote:
PS. Is the collision-generator used in the attack code open source?
As I posted before, Alexander Klink and Julian Wälde gave
On 01/02/2012 06:35 PM, Georg Brandl wrote:
On 01/02/2012 03:41 PM, Antoine Pitrou wrote:
On Mon, 2 Jan 2012 14:44:49 +1000
Nick Coghlanncogh...@gmail.com wrote:
He keeps leaving them out, I occasionally tell him they should always
be included (most recently this came up when we gave
On Mon, Jan 2, 2012 at 12:26, francis franci...@email.de wrote:
On 01/02/2012 06:35 PM, Georg Brandl wrote:
On 01/02/2012 03:41 PM, Antoine Pitrou wrote:
On Mon, 2 Jan 2012 14:44:49 +1000
Nick Coghlanncogh...@gmail.com wrote:
He keeps leaving them out, I occasionally tell him they should
On Mon, Jan 2, 2012 at 7:18 PM, Christian Heimes li...@cheimes.de wrote:
Am 02.01.2012 06:55, schrieb Paul McMillan:
I think Ruby uses FNV-1 with a salt, making it less vulnerable to
this. FNV is otherwise similar to our existing hash function.
For the record, cryptographically strong hash
On Mon, Jan 2, 2012 at 10:53 PM, Alexey Borzenkov sna...@gmail.com wrote:
On Mon, Jan 2, 2012 at 7:18 PM, Christian Heimes li...@cheimes.de wrote:
Am 02.01.2012 06:55, schrieb Paul McMillan:
I think Ruby uses FNV-1 with a salt, making it less vulnerable to
this. FNV is otherwise similar to our
-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
@francis
Like indent ?
http://www.linuxmanpages.com/man1/indent.1.php
@brian
I don't think this is a problem to the point that it needs to be fixed
via automation. The code I write is the code I build and test, so I'd
rather not have some script that goes in and modifies it to some
accepted
On Mon, Jan 2, 2012 at 1:16 AM, PJ Eby p...@telecommunity.com wrote:
On Sun, Jan 1, 2012 at 10:28 PM, Jim Jewett jimjjew...@gmail.com wrote:
Given the wording requiring a real dictionary, I would have assumed
that it was OK (if perhaps not sensible) to do pointer arithmetic and
access the
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 01/02/2012 10:02 PM, julien tayon wrote:
@francis
Like indent ?
http://www.linuxmanpages.com/man1/indent.1.php
Thank you, I wasn't aware of this one !
___
Python-Dev mailing list
Python-Dev@python.org
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 Mon, Jan 2, 2012 at 4:07 PM, Jim Jewett jimjjew...@gmail.com wrote:
On Mon, Jan 2, 2012 at 1:16 AM, PJ Eby p...@telecommunity.com wrote:
On Sun, Jan 1, 2012 at 10:28 PM, Jim Jewett jimjjew...@gmail.com
wrote:
Given the wording requiring a real dictionary, I would have assumed
that it
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 06:35 PM, Georg Brandl wrote:
Exactly. Especially for reviews of patches from non-core people, we
should exercise a lot of restraint: as the committers, I think we can be
expected to bite the sour bullet and apply our uniform style (such as
it is).
It is tiresome, if not
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
On Jan 02, 2012, at 06:38 PM, Georg Brandl wrote:
I wouldn't expect too much -- they seem rather keen on cheap laughs:
http://twitter.com/#!/bk3n/status/152068096448921600/photo/1/large
Heh, so yeah, it won't be me contacting them.
-Barry
___
43 matches
Mail list logo
