Re: [Python-Dev] PEP 7 clarification request: braces
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 without braces. Even when the compiler picks it up, it's still a wasted edit-compile cycle. More importantly though, this approach makes the rules too complicated. Always use braces is simple and easy, and the only cost is the extra line of vertical whitespace for the closing brace. (I personally don't like even the exception made for single clause if statements, but that's already too prevalent in the code base to do anything about. Hence the 4-line example in my original post.) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 7 clarification request: braces
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 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.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 7 clarification request: braces
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 context. If the answer is either form is OK, I'm actually fine with that (and will update PEP 7 accordingly). However, I have long read PEP 7 as *requiring* the braces, and until noticing their absence in some of Benjamin's checkins and the recent conflicting advice we gave when reviewing the same patch, I had never encountered their absence in the CPython code base outside the one-liner/two-liner case*. Since I *do* feel strongly that leaving them out is a mistake that encourages future defects, and read PEP 7 as agreeing with that (aside from the general follow conventions in surrounding code escape clause), I figured it was better to bring it up explicitly and clarify PEP 7 accordingly (since what is currently there is clearly ambiguous enough for two current committers to have diametrically opposed views on what it says). Cheers, Nick. * That is, constructs like: if (error_condition) return -1; if (error_condition) return -1; -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hash collision security issue (now public)
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 our proposed changes. They indicate that a non-zero start value is sufficient to prevent the attack, but D. J. Bernstein disagrees with them. He also has indicated a willingness to look at our solution. Great. My main concern currently is that there should be no noticeable slowdown for 64 bit builds which are apparently not vulnerable and which therefore would get no benefit. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hash collision security issue (now public)
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? (refer to yesterday's #python-dev discussion) I think Ruby uses FNV-1 with a salt, making it less vulnerable to this. FNV is otherwise similar to our existing hash function. Again, we could re-use FNV-1's primes, since they claim they have better dispersion properties than the average prime. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 7 clarification request: braces
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;
}
Good, I was afraid python-dev was getting a bit futile with all these
security concerns about hash functions.
I don't like having the else on the same line as the closing brace,
and prefer:
if (cond) {
statement;
}
else {
statement;
}
That said, I agree with Benjamin: the shorter form is visually lighter
and should not be frown upon.
Regards
Not-frowning Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 7 clarification request: braces
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
if (cond) {
statement;
} else {
statement;
}
by saying braces as shown, and then showing them like this:
if (mro != NULL) {
...
}
else {
...
}
That said, I agree with Benjamin: the shorter form is visually lighter
and should not be frown upon.
Me too.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 7 clarification request: braces
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 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 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 else clause at all)
Since Benjamin doesn't accept the current brace example in PEP 7 as
normative for the case above, I'm bringing it up here to seek
clarification.
I've always valued readability and consistency above brevity, and Python
does too. *Sometimes* using braces in C is a recipe for confusion, and
only adds to the cognitive load in reading the code. The examples
elsewhere in this thread of mistakes and noisy diffs due to leaving out
the braces are plenty of reason for me to always include braces.
The current code uses a mixture of styles, but that doesn't mean we need
to allow any style in the future. I'm in favor of PEP 7 being amended
to either require or strongly favor the braces-always style. Note:
while we're reading the tea-leaves in PEP 7, it has an example of a
single-line if clause with no braces.
Some people favor the braces-sometimes style because it leads to
lighter code. I think that's a misguided optimization. Consistency
is better than reducing the line count.
--Ned.
Cheers,
Nick.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hash collision security issue (now public)
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 reasons, is there a reason the overflow strategy for insertion has to be buckets containing lists? How about double-hashing, etc? Python's dict implementation doesn't use bucket but open addressing (aka closed hashed table). The algorithm for conflict resolution doesn't use double hashing. Instead it takes the original and (in most cases) cached hash and perturbs the hash with a series of add, multiply and bit shift ops. In an attack, this is still O(collisions) per probe (as any scheme where the address of the nth collision is a function of only the hash), where double hashing should be roughly O(1) (with double the coefficient). But that evidently imposes too large a performance burden on non-evil users, so it's not worth thinking about whether roughly O(1) is close enough to O(1) to deter or exhaust attackers. I withdraw the suggestion. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Code reviews
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 much about style in code reviews. There are two bad things which can happen: - your advice conflicts with advice given by another reviewer (perhaps on another issue) - the contributor feels drowned under tiresome requests for style fixes (please indent continuation lines this way) Both are potentially demotivating. A contributor can have his/her own style if it doesn't adversely affect code quality. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 7 clarification request: braces
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 PyDict_MAXFREELIST Py_TYPE(mp) == PyDict_Type)
free_list[numfree++] = mp;
else
Py_TYPE(mp)-tp_free((PyObject *)mp);
There's even things like this:
if (ep-me_key == dummy)
freeslot = ep;
else {
if (ep-me_hash == hash unicode_eq(ep-me_key, key))
return ep;
freeslot = NULL;
}
where I would normally put braces on both statements.
I think claims of its maintainability are exaggerated. (If someone
could cite an example of a bug caused by braces, I'd be interested to
see it.) If I start editing one of the bodies, emacs will dedent, so
that I know I'm back to the containing block. By virtue of being 5
lines long, it's a very easy case to see and fix as you edit it.
I think it's fine Nick raised this. PEP 7 is not very explicit about
braces at all.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: fix some possible refleaks from PyUnicode_READY error conditions
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 refleaks from PyUnicode_READY error conditions
files:
Objects/unicodeobject.c | 80
1 files changed, 56 insertions(+), 24 deletions(-)
diff --git a/Objects/unicodeobject.c b/Objects/unicodeobject.c
--- a/Objects/unicodeobject.c
+++ b/Objects/unicodeobject.c
@@ -9132,10 +9132,15 @@
Py_ssize_t len1, len2;
str_obj = PyUnicode_FromObject(str);
-if (!str_obj || PyUnicode_READY(str_obj) == -1)
+if (!str_obj)
return -1;
sub_obj = PyUnicode_FromObject(substr);
-if (!sub_obj || PyUnicode_READY(sub_obj) == -1) {
+if (!sub_obj) {
+Py_DECREF(str_obj);
+return -1;
+}
+if (PyUnicode_READY(substr) == -1 || PyUnicode_READY(str_obj) == -1) {
Shouldn't the first one be PyUnicode_READY(sub_obj) ?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: fix some possible refleaks from PyUnicode_READY error conditions
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 09:00:30 2012 -0600
summary:
fix some possible refleaks from PyUnicode_READY error conditions
files:
Objects/unicodeobject.c | 80
1 files changed, 56 insertions(+), 24 deletions(-)
diff --git a/Objects/unicodeobject.c b/Objects/unicodeobject.c
--- a/Objects/unicodeobject.c
+++ b/Objects/unicodeobject.c
@@ -9132,10 +9132,15 @@
Py_ssize_t len1, len2;
str_obj = PyUnicode_FromObject(str);
- if (!str_obj || PyUnicode_READY(str_obj) == -1)
+ if (!str_obj)
return -1;
sub_obj = PyUnicode_FromObject(substr);
- if (!sub_obj || PyUnicode_READY(sub_obj) == -1) {
+ if (!sub_obj) {
+ Py_DECREF(str_obj);
+ return -1;
+ }
+ if (PyUnicode_READY(substr) == -1 || PyUnicode_READY(str_obj) == -1) {
Shouldn't the first one be PyUnicode_READY(sub_obj) ?
Yes.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hash collision security issue (now public)
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 function. I've pushed a new patch http://hg.python.org/features/randomhash/rev/0a65d2462e0c The changeset adds the murmur3 hash algorithm with some minor changes, for example more random seeds. At first I was worried that murmur might be slower than our old hash algorithm. But in fact it seems to be faster! Pybench 10 rounds on my Core2 Duo 2.60: py3k: 3.230 sec randomahash: 3.182 sec Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hash collision security issue (now public)
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 a long-running server, there must be plenty of ways information can leak that will help guessing that start value. The alternative, to provide a dict-like datastructure for use with untrusted input, deserves consideration. Perhaps something simpler than a balanced tree would do? How about a dict-like class that is built on a lazily sorted list? Insertions basically just do list.append and set a dirty-flag, and lookups use bisect - sorting first if the dirty-flag is set. It wouldn't be complete dict replacement by any means, mixing insertions and lookups would have terrible performance, but for something like POST parameters it should be good enough. I half expected to find something like that on activestate recipes already, but couldn't find any. regards, Anders ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hash collision security issue (now public)
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 in not hearing from Python, I presume they would welcome engagement. Somebody should contact Alexander and Julian to let them know, that we are working on the matter. It should be somebody official for the initial contact, too. I've included Guido (BDFL), Barry (their initial security contact) and MvL (most prominent German core dev) in CC, as they are the logical choice for me. I'm willing to have a phone call with them once the contact has been established. IMHO it's slightly easier to talk in native tongue -- Alexander and Julian are German, too. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Code reviews
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). Oh, by the way, this is also why I avoid arguing too much about style in code reviews. There are two bad things which can happen: - your advice conflicts with advice given by another reviewer (perhaps on another issue) - the contributor feels drowned under tiresome requests for style fixes (please indent continuation lines this way) Both are potentially demotivating. A contributor can have his/her own style if it doesn't adversely affect code quality. 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 downright disappointing, to get reviews that are basically nothing wrong, but please submit again with one more empty line between the classes, and definitely not the way to attract more contributors. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hash collision security issue (now public)
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 hash...@alech.de. Since they indicated disappointment in not hearing from Python, I presume they would welcome engagement. Somebody should contact Alexander and Julian to let them know, that we are working on the matter. It should be somebody official for the initial contact, too. I've included Guido (BDFL), Barry (their initial security contact) and MvL (most prominent German core dev) in CC, as they are the logical choice for me. I'm willing to have a phone call with them once the contact has been established. IMHO it's slightly easier to talk in native tongue -- Alexander and Julian are German, too. I wouldn't expect too much -- they seem rather keen on cheap laughs: http://twitter.com/#!/bk3n/status/152068096448921600/photo/1/large Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hash collision security issue (now public)
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 their project email as hash...@alech.de. Since they indicated disappointment in not hearing from Python, I presume they would welcome engagement. Somebody should contact Alexander and Julian to let them know, that we are working on the matter. It should be somebody official for the initial contact, too. I've included Guido (BDFL), Barry (their initial security contact) and MvL (most prominent German core dev) in CC, as they are the logical choice for me. I'm willing to have a phone call with them once the contact has been established. IMHO it's slightly easier to talk in native tongue -- Alexander and Julian are German, too. I'm not sure I see the point -- just give them a link to the python-dev archives. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Code reviews
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 conflicting advice to a patch contributor). Oh, by the way, this is also why I avoid arguing too much about style in code reviews. There are two bad things which can happen: - your advice conflicts with advice given by another reviewer (perhaps on another issue) - the contributor feels drowned under tiresome requests for style fixes (please indent continuation lines this way) Both are potentially demotivating. A contributor can have his/her own style if it doesn't adversely affect code quality. 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 downright disappointing, to get reviews that are basically nothing wrong, but please submit again with one more empty line between the classes, and definitely not the way to attract more contributors. Hi to all member of this list, I'm not a Python-Dev (only some very small patches over core-mentorship list. Just my 2cents here). I would try to relax this conflicts with a script that does the reformatting itself. If that reformatting where part of the process itself do you thing that that would be an issue anymore? PS: I know that there’s a pep8 checker so it could be transformed into a reformatter but I don't know if theres a pep7 checker (reformater) Best regards! francis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Code reviews
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 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 style in code reviews. There are two bad things which can happen: - your advice conflicts with advice given by another reviewer (perhaps on another issue) - the contributor feels drowned under tiresome requests for style fixes (please indent continuation lines this way) Both are potentially demotivating. A contributor can have his/her own style if it doesn't adversely affect code quality. 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 downright disappointing, to get reviews that are basically nothing wrong, but please submit again with one more empty line between the classes, and definitely not the way to attract more contributors. Hi to all member of this list, I'm not a Python-Dev (only some very small patches over core-mentorship list. Just my 2cents here). I would try to relax this conflicts with a script that does the reformatting itself. If that reformatting where part of the process itself do you thing that that would be an issue anymore? 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 format, then have to go through the build/test dance again. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hash collision security issue (now public)
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 functions are in the neighborhood of 400% slower than our existing hash function. I've pushed a new patch http://hg.python.org/features/randomhash/rev/0a65d2462e0c It seems for 32-bit version you are using pid for the two constants. Also, it's unclear why you even need to use a random constant for the final pass, you already use random constant as an initial h1, and it should be enough, no need to use for k1. Same for 128-bit: k1, k2, k3, k4 should be initialized to zero, these are key data, they don't need to be mixed with anything. Also, I'm not sure how portable is the always_inline attribute, is it supported on all compilers and all platforms? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hash collision security issue (now public)
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 existing hash function. For the record, cryptographically strong hash functions are in the neighborhood of 400% slower than our existing hash function. I've pushed a new patch http://hg.python.org/features/randomhash/rev/0a65d2462e0c It seems for 32-bit version you are using pid for the two constants. Also, it's unclear why you even need to use a random constant for the final pass, you already use random constant as an initial h1, and it should be enough, no need to use for k1. Same for 128-bit: k1, k2, k3, k4 should be initialized to zero, these are key data, they don't need to be mixed with anything. Sorry, sent too soon. What I mean is that you're initializing a pretty big array of values when you only need a 32-bit value. Pid, in my opinion might be too predictable, it would be a lot better to simply hash pid and gettimeofday bytes to produce this single 32-bit value and use it for h1, h2, h3 and h4 in both 32-bit and 128-bit versions. Also, I'm not sure how portable is the always_inline attribute, is it supported on all compilers and all platforms? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 7 clarification request: braces
-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 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 else
clause at all)
Could you explain how these two cases differ with regard to
maintenance?
Sure: always including KR style braces for compound statements (even
when they aren't technically necessary) means that indentation ==
control flow, just like Python. Indent your additions correctly, and
the reader and compiler will agree on what they mean:
if (cond) { statement; } else { statement; addition; /* Reader and
compiler agree this is part of the else clause */ }
if (cond) statement; else statement; addition; /* Uh-oh, should have
added braces */
I've been trying to convince Benjamin that there's a reason always
include the braces is accepted wisdom amongst many veteran C
programmers (with some allowing an exception for one-liners), but he
isn't believing me, and I'm not going to go through and edit every
single one of his commits to add them.
FWIW, +1 to mandating braces-always (even for one liners): the future
maintenance burden isn't worth the trouble of the exception. In the days
when I did C / C++ / Java coding as my main gig, braceless code was
routinely a bug magnet *for the team*.
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8CEpwACgkQ+gerLs4ltQ5vTwCbBjlToJ2yZh4Ra+tNkqMVIaLj
NfUAnjAfkDE0BPus1g33hd84tkGonUzd
=K1p9
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 7 clarification request: braces
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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Code reviews
@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 format, then have to go through the build/test dance again. Well, it breaks committing since it adds non significative symbols, therefore bloats the diffs. But as far as I am concerned for using it a long time ago, it did not break anything, it was pretty reliable. my 2c * 0.1 -- jul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] That depends on what the meaning of is is (was Re: http://mail.python.org/pipermail/python-dev/2011-December/115172.html)
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 keys/values/hashes directly. (Though if the breakage was between python versions, I would feel guilty about griping too loudly.) If you're going to be a language lawyer about it, I would simply point out that all the spec requires is that type(env) is dict -- it says nothing about how Python defines type or is or dict. So, you're on your own with that one. ;-) But the public header file http://hg.python.org/cpython/file/3ed5a6030c9b/Include/dictobject.h defines the typedef structs for PyDictEntry and _dictobject. What is the purpose of the requiring a real dict without also promising what the header file promises? -jJ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 7 clarification request: braces
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 be readable, and code reviews are the best way to achieve that--not endlessly specific formatting rules. Have there been bugs in CPython that the proposed new PEP 7 rule would have prevented? /arry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 7 clarification request: braces
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 was cleanest to their eyes in a given context. I'm with Raymond. Code should be readable, and code reviews are the best way to achieve that--not endlessly specific formatting rules. Have there been bugs in CPython that the proposed new PEP 7 rule would have prevented? 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 code. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 7 clarification request: braces
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 cleanest to their eyes in a given context. I'm with Raymond. Code should be readable, and code reviews are the best way to achieve that--not endlessly specific formatting rules. Have there been bugs in CPython that the proposed new PEP 7 rule would have prevented? I've found that until someone has experienced multiple nasty bugs caused by not always using braces, it's nearly impossible to convince them of why you should. Afterwards it'simpossible to convince them (me) that you shouldn't always use braces. I'd also point out that if you're expecting braces, not having them can make the code less readable. A consistent format tends to make for more readable code. Cheers, Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Code reviews
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-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 7 clarification request: braces
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 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 always-use-braces mandate, A LOT of code will need to
be changed.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 7 clarification request: braces
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 problems that can't be solved by braces ;-) Raymond___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 7 clarification request: braces
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 always-use-braces mandate, A LOT of code will need to be changed. I'm sure we can agree that 1) Nick isn't pushing through anything, this is a discussion about what to do, and 2) even if we agree to change PEP 7, no one would advocate having to go through all the C code to change it to a newly-agreed style. --Ned. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ned%40nedbatchelder.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] That depends on what the meaning of is is (was Re: http://mail.python.org/pipermail/python-dev/2011-December/115172.html)
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 was OK (if perhaps not sensible) to do pointer arithmetic and access the keys/values/hashes directly. (Though if the breakage was between python versions, I would feel guilty about griping too loudly.) If you're going to be a language lawyer about it, I would simply point out that all the spec requires is that type(env) is dict -- it says nothing about how Python defines type or is or dict. So, you're on your own with that one. ;-) But the public header file http://hg.python.org/cpython/file/3ed5a6030c9b/Include/dictobject.h defines the typedef structs for PyDictEntry and _dictobject. What is the purpose of the requiring a real dict without also promising what the header file promises? Er, just because it's in the .h doesn't mean it's in the public API. But in any event, if you're actually serious about this, I'd just point out that: 1. The struct layout doesn't guarantee anything about insertion or lookup algorithms, 2. If the data structure were changed, the header file would obviously change as well, and 3. ISTM that Python does not even promise inter-version ABI compatibility for internals like the dict object layout. Are you seriously writing code that relies on the C structure layout of dicts? Because really, that was SO not the point of the dict type requirement. It was so that you could use Python's low-level *API* calls, not muck about with the data structure directly. I'm occasionally considered notorious for abusing Python internals, but even I have to draw the line somewhere. ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 7 clarification request: braces
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 *did* use
} else { (mainly because I write my if statements that way, and
nobody had ever pointed out to me that the C style guide actually says
otherwise).
So I'm happy enough with leaving PEP 7 alone and letting the stylistic
inconsistencies stand (even going forward). I agree in these days of
auto-indenting editors and automated test suites, the maintenance
benefits of always requiring the braces are significantly less than
they used to be.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 7 clarification request: braces
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 clutter. If Nick pushes through an always-use-braces mandate, A LOT of code will need to be changed. Nah, I was asking a genuine question, not pushing anything in particular. I *thought* the code base was more consistent than it is, but it turns out that was an error of perception on my part, rather than an objective fact. With my perception of the status quo corrected, I can stop worrying about preserving a non-existent consistency. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 7 clarification request: braces
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.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 7 clarification request: braces
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 beautiful examples in KR's The C Programming Language, then they've got problems that can't be solved by braces ;-) Now that's just hyperbole ;) If you've got a mix of braces and non-braces in a chunk of code, it's very easy for the mind to skip over the non-brace blocks as not being blocks. I know it's not something I'm likely to mess up when reading the code in-depth, but if I'm skimming over trying to understand the gist of the code or looking for what should be an obvious bug, a block that's not brace-delimited is more likely to be missed than one that is (when amongst other blocks that are). If we had the option of just use indentation in C I'd advocate that. Failing that, I find that consistent usage of braces is preferable. Cheers, Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 7 clarification request: braces
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 committers have had good instincts about when braces add clarity and when they add clutter. If Nick pushes through an always-use-braces mandate, A LOT of code will need to be changed. Nah, I was asking a genuine question, not pushing anything in particular. I *thought* the code base was more consistent than it is, but it turns out that was an error of perception on my part, rather than an objective fact. With my perception of the status quo corrected, I can stop worrying about preserving a non-existent consistency. Amen. And, as the (nominal) author of the PEP, the PEP didn't mean to state an opinion on whether braces are mandatory. It only meant to state how they should be placed when they are there. It's true that there are other readings possible, but that's what I meant. If someone wants to change the wording to clarify this, go right ahead. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Code reviews
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 downright disappointing, to get reviews that are basically nothing wrong, but please submit again with one more empty line between the classes, and definitely not the way to attract more contributors. I think it's fine in a code review to point out where the submission misses the important consistency points, but not to hold up merging the changes because of that. You want to educate and motivate so that the next submission comes closer to our standards. The core dev who commits the change can clean up style issues. -Barry P.S. +1 for the change to PEP 7. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 7 clarification request: braces
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 code. +1 The other reason why style guides exist is to give contributors some sense of what they should shoot for. I've worked on existing code bases where there's so little consistency I can't tell what the author's preferences are even if I wanted to adhere to them. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hash collision security issue (now public)
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
