Hello,
Sorry to annoy the very busy core devs :) out of the blue
I quite noticed people were
1) wanting to have a new dict for Xmas
2) strongly resenting dict addition.
Even though I am not a good developper, I have come to a definition of
addition that would follow algebraic rules, and not
...oops, I did not intend to send this to the mailing list. I
apologize for the accidental off topic.
On Fri, Dec 30, 2011 at 7:40 AM, lahwran blendmaster1...@gmail.com wrote:
I don't want to post to the mailing list about this; But I must say, I
found your email very entertaining. You have a
I don't want to post to the mailing list about this; But I must say, I
found your email very entertaining. You have a good sense of humor.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Hi Julien,
Don't despair! I have tried to get people to warm up to dict addition too
-- in fact it was my counter-proposal at the time when we were considering
adding sets to the language. I will look at your proposal, but I have a
point of order first: this should be discussed on python-ideas,
ACTIVITY SUMMARY (2011-12-23 - 2011-12-30)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open3178 (+10)
closed 22288 (+16)
total 25466 (+26)
Open issues
On Thu, Dec 29, 2011 at 11:55, antoine.pitrou
python-check...@python.org wrote:
http://hg.python.org/cpython/rev/cf57ef65bcd0
changeset: 74194:cf57ef65bcd0
user: Antoine Pitrou solip...@pitrou.net
date: Thu Dec 29 18:54:15 2011 +0100
summary:
Issue #12715: Add an optional
On Fri, 30 Dec 2011 13:29:36 -0600
Brian Curtin br...@python.org wrote:
Can we expect that readers on Windows know how os.symlink works, or
should the stipulations of os.symlink usage also be laid out or at
least linked to from there?
I assume it won't make a difference in real life, since
On Fri, Dec 30, 2011 at 13:39, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 30 Dec 2011 13:29:36 -0600
Brian Curtin br...@python.org wrote:
Can we expect that readers on Windows know how os.symlink works, or
should the stipulations of os.symlink usage also be laid out or at
least linked
In http://mail.python.org/pipermail/python-dev/2011-December/115138.html,
Christian Heimes
pointed out that
... we don't have to alter the outcome of hash ... We just need to reduce the
chance that
an attacker can produce collisions in the dict (and set?)
I'll state it more strongly. hash
Le 29/12/2011 02:28, Michael Foord a écrit :
A paper (well, presentation) has been published highlighting security problems
with the hashing algorithm (exploiting collisions) in many programming
languages Python included:
Jim Jewett wrote:
My personal opinion is that accepting *and parsing* enough data for
this to be a problem
is enough of an edge case that I don't want normal dicts slowed down
at all for this; I would
therefore prefer that the change be restricted to such a compile-time
switch, with current
Le 29/12/2011 14:19, Christian Heimes a écrit :
Perhaps the dict code is a better place for randomization.
The problem is the creation of a dict with keys all having the same hash
value. The current implementation of dict uses a linked-list. Adding a
new item requires to compare the new key
In case the watchdog is not a viable solution as I had assumed it was, I
think it's more reasonable to indeed consider adding a flag to Python
that allows randomization of hashes optionally before startup.
A flag will only be needed if the overhead of the fix is too high.
However as it was
Am 31.12.2011 03:31, schrieb Victor Stinner:
Le 29/12/2011 14:19, Christian Heimes a écrit :
Perhaps the dict code is a better place for randomization.
The problem is the creation of a dict with keys all having the same hash
value. The current implementation of dict uses a linked-list.
Am 31.12.2011 03:19, schrieb Steven D'Aprano:
How about using a similar strategy to the current dict behaviour with
__missing__ and defaultdict? Here's my suggestion:
- If a dict subclass defines __salt__, then it is called to salt the hash
value before lookups. If __salt__ is
On 12/30/2011 8:04 PM, Jim Jewett wrote:
I'll state it more strongly. hash probably should not change (at
least for this),
I agree, especially since the vulnerability can be avoided by using 64
bit servers and will generally abate as more switch anyway.
but we may
want to consider a
16 matches
Mail list logo
