> > The section is still available in the cpython repo, and I'm waiting to
> > remove it because it's better to have some redirections in place from
> > the current urls to the new ones. I've prepared a small set of
> > RewriteRules (attached): I don't know the actual setup of apache for
> > docs.p
On Sun, Jan 15, 2012 at 2:42 PM, Steven D'Aprano wrote:
> Victor Stinner wrote:
>
>> - Marc Andre Lemburg proposes to fix the vulnerability directly in
>> dict (for any key type). The patch raises an exception if a lookup
>> causes more than 1000 collisions.
>
>
>
> Am I missing something? How doe
Guido van Rossum wrote:
On Fri, Jan 13, 2012 at 5:58 PM, Gregory P. Smith wrote:
It is perfectly okay to break existing users who had anything depending on
ordering of internal hash tables. Their code was already broken. We
*will*provide a flag and/or environment variable that can be set to t
Victor Stinner wrote:
- Marc Andre Lemburg proposes to fix the vulnerability directly in
dict (for any key type). The patch raises an exception if a lookup
causes more than 1000 collisions.
Am I missing something? How does this fix the vulnerability? It seems to me
that the only thing this d
FWIW the quick change i pastebin'ed is basically covered by the change
already under review in http://bugs.python.org/review/13704/show. I've
made my comments and suggestions there.
I looked into Modules/expat/xmlparse.c and it has an odd copy of the old
string hash algorithm entirely for its own
Hi again,
On Sat, Jan 14, 2012 at 19:09, Sandro Tosi wrote:
> Hi all,
> (another) heads-up about my current work: I've just pushed the
> "Documenting Python" doc section (ftr:
> http://docs.python.org/documenting/index.html) to devguide. That was
> possibile now that we use the same sphinx versio
My patch example does change the bytes object hash as well as Unicode.
On Jan 13, 2012 7:46 PM, wrote:
> What an implementation looks like:
>>
>> http://pastebin.com/9ydETTag
>>
>> some stuff to be filled in, but this is all that is really required.
>>
>
> I think this statement (and the patch)
Hi all,
(another) heads-up about my current work: I've just pushed the
"Documenting Python" doc section (ftr:
http://docs.python.org/documenting/index.html) to devguide. That was
possibile now that we use the same sphinx version on all the active
branches.
It was not a re-editing of the content, t
Hello,
just a heads-up: documentation for 2.7 branch has been ported to use
sphinx 1.0, so now the same syntax can be used for 2.x and 3.x
patches, hopefully easying working on both python stacks.
Cheers,
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.or
Am 14.01.2012 01:37, schrieb Benjamin Peterson:
> 2012/1/13 Guido van Rossum :
>> Really? Even though you came up with specifically to prove me wrong?
>
> Coming up with a counterexample now invalidates it?
There are two concerns here:
- is it possible to come up with an example of constructed va
Am 13.01.2012 18:08, schrieb Mark Dickinson:
> On Fri, Jan 13, 2012 at 2:57 AM, Guido van Rossum wrote:
>> How
>> pathological the data needs to be before the collision counter triggers? I'd
>> expect *very* pathological.
>
> How pathological do you consider the set
>
>{1 << n for n in range
On Sat, Jan 14, 2012 at 04:24, Éric Araujo wrote:
> Hi Sandro,
>
> Thanks for getting the ball rolling on this. One style for markup, one
> Sphinx version to code our extensions against and one location for the
> documenting guidelines will make our work a bit easier.
thanks :) I'm happy to help
On Jan 14, 2012 5:56 PM, "Georg Brandl" wrote:
>
> On 01/14/2012 07:53 AM, Nick Coghlan wrote:
> > I agree, but it's one of the challenges of a long-lived branch like
> > the PEP 380 one (I believe some of these cosmetic changes started life
> > in Greg's original patch and separating them out wo
I think this statement (and the patch) is wrong. You also need to change
the byte string hashing, at least for 2.x. This I consider the biggest
flaw in that approach - other people may have written string-like objects
which continue to compare equal to a string but now hash different.
They're un
On Sat, 14 Jan 2012 13:55:22 +1100
Steven D'Aprano wrote:
> On 14/01/12 12:58, Gregory P. Smith wrote:
>
> > I do like *randomly seeding the hash*. *+1*. This is easy. It can easily be
> > back ported to any Python version.
> >
> > It is perfectly okay to break existing users who had anything dep
On Sat, 14 Jan 2012 04:45:57 +0100
mar...@v.loewis.de wrote:
> > What an implementation looks like:
> >
> > http://pastebin.com/9ydETTag
> >
> > some stuff to be filled in, but this is all that is really required.
>
> I think this statement (and the patch) is wrong. You also need to change
> the
Jack Diederich writes:
> On Thu, Jan 12, 2012 at 9:57 PM, Guido van Rossum wrote:
> > Hm... I started out as a big fan of the randomized hash, but thinking more
> > about it, I actually believe that the chances of some legitimate app having
> >>1000 collisions are way smaller than the chances
Finally, a reason to use Python 3 ;-)
Chris
On 13/01/2012 16:00, Guido van Rossum wrote:
AWESOME!!!
On Fri, Jan 13, 2012 at 4:14 AM, Nick Coghlan mailto:ncogh...@gmail.com>> wrote:
I marked PEP 380 as Final this evening, after pushing the tested and
documented implementation to hg.pyt
18 matches
Mail list logo
