On Mon, Jan 2, 2012 at 4:22 PM, Ron Adam 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 without brace
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
On Mon, Jan 2, 2012 at 6:47 PM, 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.
If the answer i
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 at
On Sun, 1 Jan 2012 21:55:52 -0800
Paul McMillan 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?
(refer to y
On Mon, 2 Jan 2012 14:44:49 +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;
> }
Go
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
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 occas
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
> > compat
On Mon, 2 Jan 2012 14:44:49 +1000
Nick Coghlan 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 much about sty
2012/1/1 Nick Coghlan :
> 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 < PyDict_MAXFREELIST && Py_TYPE
On Mon, 02 Jan 2012 16:00:50 +0100
benjamin.peterson wrote:
> http://hg.python.org/cpython/rev/d5cda62d0f8c
> changeset: 74236:d5cda62d0f8c
> user:Benjamin Peterson
> date:Mon Jan 02 09:00:30 2012 -0600
> summary:
> fix some possible refleaks from PyUnicode_READY error conditi
2012/1/2 Antoine Pitrou :
> On Mon, 02 Jan 2012 16:00:50 +0100
> benjamin.peterson wrote:
>> http://hg.python.org/cpython/rev/d5cda62d0f8c
>> changeset: 74236:d5cda62d0f8c
>> user: Benjamin Peterson
>> date: Mon Jan 02 09:00:30 2012 -0600
>> summary:
>> fix some possible refleak
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 has
> 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? F
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 disappoint
On 01/02/2012 03:41 PM, Antoine Pitrou wrote:
> On Mon, 2 Jan 2012 14:44:49 +1000
> Nick Coghlan 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 th
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
>> ema
On Mon, Jan 2, 2012 at 7:47 AM, 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 pr
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 Coghlan 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 pat
On Mon, Jan 2, 2012 at 12:26, francis 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 Coghlan wrote:
He keeps leaving them out, I occasionally tell him they should always
be
On Mon, Jan 2, 2012 at 7:18 PM, Christian Heimes 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 functions
On Mon, Jan 2, 2012 at 10:53 PM, Alexey Borzenkov wrote:
> On Mon, Jan 2, 2012 at 7:18 PM, Christian Heimes 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.
-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
> 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
2012/1/1 Nick Coghlan :
>
> 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
___
P
@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
> accepte
On Mon, Jan 2, 2012 at 1:16 AM, PJ Eby wrote:
> On Sun, Jan 1, 2012 at 10:28 PM, Jim Jewett 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 keys/values/hashes directly. (Though
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 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 cleanes
On 3 January 2012 08:50, Larry Hastings 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 cleanest to th
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
http://mail.python.org/mailman/listinfo/python-d
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 o
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 K&R's The C Programming Language, then they've got pro
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 alwa
On Mon, Jan 2, 2012 at 4:07 PM, Jim Jewett wrote:
> On Mon, Jan 2, 2012 at 1:16 AM, PJ Eby wrote:
> > On Sun, Jan 1, 2012 at 10:28 PM, Jim Jewett
> wrote:
> >>
> >> Given the wording requiring a real dictionary, I would have assumed
> >> that it was OK (if perhaps not sensible) to do pointer ar
On Tue, Jan 3, 2012 at 12:54 AM, Benjamin Peterson 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 *did* use
"} else {"
On Tue, Jan 3, 2012 at 8:32 AM, 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 pushe
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
http://mail.python
On 3 January 2012 09:55, Raymond Hettinger wrote:
>
> 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
> example
On Mon, Jan 2, 2012 at 4:27 PM, Nick Coghlan wrote:
> On Tue, Jan 3, 2012 at 8:32 AM, 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 wh
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
___
Pytho
43 matches
Mail list logo
