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 somet
...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 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 good sense of humor.
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:
h
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, no
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 wit
On Thu, Dec 29, 2011 at 11:55, antoine.pitrou
wrote:
> http://hg.python.org/cpython/rev/cf57ef65bcd0
> changeset: 74194:cf57ef65bcd0
> user: Antoine Pitrou
> date: Thu Dec 29 18:54:15 2011 +0100
> summary:
> Issue #12715: Add an optional symlinks argument to shutil functions
> (
On Fri, 30 Dec 2011 13:29:36 -0600
Brian Curtin 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 symlinks are
q
On Fri, Dec 30, 2011 at 13:39, Antoine Pitrou wrote:
> On Fri, 30 Dec 2011 13:29:36 -0600
> Brian Curtin 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 assu
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:
http://events.ccc.de/congress/2011/Fahrplan/attachments/2007_2
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 beha
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 t
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 sai
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 und
Am 31.12.2011 03:22, schrieb Victor Stinner:
> The creation of a Python dictionary has a complexity of O(n) in most
> cases, but O(n^2) in the *worst* case. The attack tries to go into the
> worst case. It requires to compute a set of N keys having the same hash
> value (hash(key1) == hash(key2)
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 dif
17 matches
Mail list logo
