> 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
Hello,
all proposed fixes for a randomized hashing function raise and fall with
a good random number generator to feed the random seed. The seed must be
created very early in the startup phase of the interpreter, preferable
before the basic types are initialized. CPython already have multiple
sour
FWIW I'm against forcing braces to be used. Readability is the highest
concern, and this should be at the discretion of the contributor. A
code formatting tool, or compiler extension is the only proper handle
this, and neither are in use or available.
On Tue, Jan 3, 2012 at 7:44 PM, "Martin v. Löw
Matt Joiner writes:
> Readability is the highest concern, and this should be at the
> discretion of the contributor.
That's quite backwards. "Readability" is community property, and has
as much, if not more, to do with common convention as with some
absolute metric. The "contributor's discret
Hi,
I'm not a core Python developer, but it may be intesting to use a real
Crush resistant RNG, as one from Random123 (a parallel random generator
that is Crush resistant, contrary to the Mersenne Twister, and without a
state).
Cheers,
Matthieu Brucher
2012/1/3 Christian Heimes
> Hello,
>
> a
On Tue, 03 Jan 2012 14:18:34 +0100
Christian Heimes wrote:
>
> I suggest Python/random.c as source file and Python/pyrandom.h as header
> file. Comments?
Looks good on the principle. The API names for MT are a bit ugly.
> The RNG should be suitable for cryptography.
Sounds like too strong a re
Am 03.01.2012 18:23, schrieb Matthieu Brucher:
> Hi,
>
> I'm not a core Python developer, but it may be intesting to use a real
> Crush resistant RNG, as one from Random123 (a parallel random generator
> that is Crush resistant, contrary to the Mersenne Twister, and without a
> state).
Hello Matt
Stephen J. Turnbull wrote:
Matt Joiner writes:
> Readability is the highest concern, and this should be at the
> discretion of the contributor.
That's quite backwards. "Readability" is community property, and has
as much, if not more, to do with common convention as with some
absolute metric
On Dec 31, 2011, at 04:56 PM, Guido van Rossum wrote:
>Is there a tracker issue yet? The discussion should probably move there.
I think the answer to this was "no"... until now.
http://bugs.python.org/issue13703
Proposed patches should be linked to this issue now. Please nosy yourself if
you w
On Mon, Jan 2, 2012 at 7:16 PM, PJ Eby wrote:
> On Mon, Jan 2, 2012 at 4:07 PM, Jim Jewett wrote:
>> 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 th
Christian Heimes wrote:
[...]
I propose an addition to the current Python C API:
int PyOS_URandom(char *buf, Py_ssize_t len)
Read "len" chars from the OS's RNG into the pre-allocated buffer "buf".
The RNG should be suitable for cryptography.
Since some platforms may not have /dev/urandom, we
> The core RNG is going to be part of the randomized hashing function
> patch. The patch will be applied to all Python version from 2.6 to 3.3.
> Some people may want to applied it to 2.4 and 2.5, too. As the patch is
> going to affect six to eight Python versions, it should introduce as few
> new
A randomized hash doesn't need cryptographic RNG (which are slow and
need a lot of new code), and the new hash function should maybe not be
cryptographic. We need to make the DoS more expensive for the
attacker, but we don't need to add "too much security" for that.
Mersenne Twister is useless her
On Tue, 3 Jan 2012 22:17:06 +0100
Victor Stinner wrote:
> A randomized hash doesn't need cryptographic RNG (which are slow and
> need a lot of new code), and the new hash function should maybe not be
> cryptographic. We need to make the DoS more expensive for the
> attacker, but we don't need to a
Christian Heimes wrote:
> Am 29.12.2011 12:13, schrieb Mark Shannon:
> > The attack relies on being able to predict the hash value for a given
> > string. Randomising the string hash function is quite straightforward.
> > There is no need to change the dictionary code.
> >
> > A possible (*untes
> Have you read the following sentence:
>
> “Since some platforms may not have /dev/urandom, we need a PRNG in the
> core, too. I therefore propose to move the Mersenne twister from
> randommodule.c into the core, too.”
I disagree. We don't need a PRNG on platforms without /dev/urandom or
any oth
"Stephen J. Turnbull" writes:
> Matt Joiner writes:
>
> > Readability is the highest concern, and this should be at the
> > discretion of the contributor.
>
> That's quite backwards. "Readability" is community property, and has
> as much, if not more, to do with common convention as with some
> Readability also includes more than just the source code; as has already
> been stated:
>
> if(cond) {
>stmt1;
> + stmt2;
> }
>
> vs.
>
> -if(cond)
> +if(cond) {
>stmt1;
> + stmt2;
> +}
>
> I find the diff version that already had braces in place much more
> readable.
Is it reall
Ethan Furman stoneleaf.us> writes:
>
> Readability also includes more than just the source code; as has already
> been stated:
>
> if(cond) {
> stmt1;
> + stmt2;
> }
>
> vs.
>
> -if(cond)
> +if(cond) {
> stmt1;
> + stmt2;
> +}
>
> I find the diff version that already had braces
PEP: XXX
Title: Interpreter support for concurrent programming
Version: $Revision$
Last-Modified: $Date$
Author: Mike Meyer
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 11-Nov-2011
Post-History:
Abstract
The purpose of this PEP is to explore strategies for makin
On 1/3/2012 5:02 PM, Bill Janssen wrote:
Software that depends on an undefined hash function for synchronization
and persistence deserves to break, IMO. There are plenty of
well-defined hash functions available for this purpose.
The doc for id() now says "This is an integer which is guarantee
> +.. c:function:: int PyUnicode_Fill(PyObject *unicode, Py_ssize_t start, \
> +Py_ssize_t length, Py_UCS4 fill_char)
> +
> + Fill a string with a character: write *fill_char* into
> + ``unicode[start:start+length]``.
> +
> + Fail if *fill_char* is bigger than the str
On Wed, Jan 4, 2012 at 8:21 AM, "Martin v. Löwis" wrote:
>> Have you read the following sentence:
>>
>> “Since some platforms may not have /dev/urandom, we need a PRNG in the
>> core, too. I therefore propose to move the Mersenne twister from
>> randommodule.c into the core, too.”
>
> I disagree.
On Tue, 03 Jan 2012 23:21:30 +0100
"Martin v. Löwis" wrote:
> > Have you read the following sentence:
> >
> > “Since some platforms may not have /dev/urandom, we need a PRNG in the
> > core, too. I therefore propose to move the Mersenne twister from
> > randommodule.c into the core, too.”
>
> I
Benjamin Peterson writes:
> Ethan Furman stoneleaf.us> writes:
> >
> > Readability also includes more than just the source code; as has already
> > been stated:
[diffs elided]
> > I find the diff version that already had braces in place much more
> > readable.
>
> There are much larg
2012/1/3 Stephen J. Turnbull :
> Benjamin Peterson writes:
> > Ethan Furman stoneleaf.us> writes:
> > >
> > > Readability also includes more than just the source code; as has already
> > > been stated:
>
> [diffs elided]
>
> > > I find the diff version that already had braces in place much mo
On Tue, Jan 3, 2012 at 7:40 PM, Mike Meyer wrote:
> STM is a relatively new technology being experimented with in newer
> languages, and in a number of 3rd party libraries (both Peak [#Peak]_
> and Kamaelia [#Kamaelia]_ provide STM facilities).
I don't know about Kamaelia, but PEAK's STM (part
Benjamin Peterson writes:
> My goodness, I was trying to make a ridiculous-sounding proposition.
In this kind of discussion, that's in the same class as "be careful
what you wish for -- because you might just get it."
___
Python-Dev mailing list
Python
28 matches
Mail list logo
