On Thu, Feb 23, 2012 at 01:15, Stephen J. Turnbull wrote:
> Brian Curtin writes:
>
> > If you want to contribute to development, I think you'll know that a
> > link about development is relevant.
>
> For values of "you" in "experienced programmers", yes. But
> translators and tech writers don't
Brian Curtin writes:
> If you want to contribute to development, I think you'll know that a
> link about development is relevant.
For values of "you" in "experienced programmers", yes. But
translators and tech writers don't consider what they do to be
"development."
__
Antoine Pitrou writes:
> How is it a "false sense of security" at all? It's the same as
> setting a private secret for e.g. session cookies in Web applications.
> As long as you don't leak the seed, it's (should be) secure.
That's true. The problem is, the precondition that you won't leak the
On Wed, Feb 22, 2012 at 18:21, Éric Araujo wrote:
> Le 11/02/2012 12:00, Eli Bendersky a écrit :
>> Well, I think the situation is pretty good now. If one goes to
>> python.org and is interested in contributing, clicking on the "Core
>> Development" link is a sensible step, right?
>
> Maybe, depen
Hi Brett,
I think this message went unanswered, so here’s a late reply:
Le 07/02/2012 23:21, Brett Cannon a écrit :
> On Tue, Feb 7, 2012 at 15:28, Dirkjan Ochtman wrote:
>> [...]
>> Anyway, I think there was enough of a python3 port for Mercurial (from
>> various GSoC students) that you can pro
Le 11/02/2012 12:00, Eli Bendersky a écrit :
> Well, I think the situation is pretty good now. If one goes to
> python.org and is interested in contributing, clicking on the "Core
> Development" link is a sensible step, right?
Maybe, depending on your knowledge of jargon. How about rewording that
On Wed, Feb 22, 2012 at 10:14 AM, Barry Warsaw wrote:
> Two more small details to address, and then I think we're ready to start
> creating release candidates.
>
> - sys.flags.hash_randomization
>
> In the tracker issue, I had previously stated a preference that this flag
> only reflect the s
On 2/22/2012 1:57 AM, Nick Coghlan wrote:
In the tracker, someone proposed that the option is necessary to synchronize
the seed across processes in a cluster. I'm sure people will use it for that
if they can.
Yeah, that use case sounds reasonable, too. Another example is that,
even within a ma
> I just cut out around 100 warnings last night in 45 minutes, so I
> don't plan on having this take several months or anything. If I get
> stuck, I'll just give it up.
Would you mind posting a batch of these to the tracker? I'd like
to review them, just to be sure we have the same understanding.
On Wed, Feb 22, 2012 at 11:55 AM, "Martin v. Löwis" wrote:
> Am 22.02.2012 19:46, schrieb Maciej Fijalkowski:
>> On Wed, Feb 22, 2012 at 9:59 AM, wrote:
>>> What is the hash of "ePjNTUhitHkL"?
>>>
>>> Regards,
>>> Martin
>>>
>>> P.S. It took me roughly 86h to compute 150 strings colliding for th
Am 22.02.2012 19:46, schrieb Maciej Fijalkowski:
> On Wed, Feb 22, 2012 at 9:59 AM, wrote:
>> What is the hash of "ePjNTUhitHkL"?
>>
>> Regards,
>> Martin
>>
>> P.S. It took me roughly 86h to compute 150 strings colliding for the 64-bit
>> hash function.
>
> You should have used pypy, should hav
On Wed, Feb 22, 2012 at 9:59 AM, wrote:
> What is the hash of "ePjNTUhitHkL"?
>
> Regards,
> Martin
>
> P.S. It took me roughly 86h to compute 150 strings colliding for the 64-bit
> hash function.
You should have used pypy, should have been faster.
___
On Wed, 22 Feb 2012 12:59:33 -0500
Barry Warsaw wrote:
> On Feb 22, 2012, at 09:04 PM, Stephen J. Turnbull wrote:
>
> >Brett Cannon writes:
> >
> > > I think that's inviting trouble if you can provide the seed. It leads to a
> > > false sense of security
> >
> >I thought the point of providing t
Two more small details to address, and then I think we're ready to start
creating release candidates.
- sys.flags.hash_randomization
In the tracker issue, I had previously stated a preference that this flag
only reflect the state of the -R command line option, not the
$PYTHONHASHSEED en
On Feb 22, 2012, at 09:04 PM, Stephen J. Turnbull wrote:
>Brett Cannon writes:
>
> > I think that's inviting trouble if you can provide the seed. It leads to a
> > false sense of security
>
>I thought the point of providing the seed was for reproducability of
>tests and the like?
>
>As for "false
What is the hash of "ePjNTUhitHkL"?
Regards,
Martin
P.S. It took me roughly 86h to compute 150 strings colliding for the
64-bit hash function.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns
On Wed, Feb 22, 2012 at 04:24:38AM +0200, Eli Bendersky wrote:
>
> Andrew, could you elaborate on your use case? Are you using cElementTree to
> do the parsing, or ElementTree (the Python implementation). Can you show a
> short code sample?
I'm mostly using ElementTree because several classes/fun
On Wed, Feb 22, 2012 at 10:04, shibturn wrote:
> On 22/02/2012 3:32am, Brian Curtin wrote:
>>
>> 1. Is anyone opposed to moving up to Level 4 warnings?
>
>
> At that level I think it complains about common things like the "do {...}
> while (0)" idiom, and the unreferenced self parameter of builtin
On 22/02/2012 3:32am, Brian Curtin wrote:
1. Is anyone opposed to moving up to Level 4 warnings?
At that level I think it complains about common things like the "do
{...} while (0)" idiom, and the unreferenced self parameter of builtin
functions.
Presumably you would have to disable those s
On Tue, Feb 21, 2012 at 23:45, wrote:
>
> Zitat von Brian Curtin :
>
>
>> While some effort has gone on to get the 32-bit build to compile
>> without warnings (thanks for that!), 64-bit still has numerous
>> warnings. Before I push forward on more of the VS2010 port, I'd like
>> to have a clean 2
On Wed, 22 Feb 2012 13:58:45 +0100
victor.stinner wrote:
>
> +/* Copy a ASCII or latin1 char* string into a Python Unicode string.
> + Return the length of the input string.
> +
> + WARNING: Don't copy the terminating null character and don't check the
> + maximum character (may write a la
On Tue, 21 Feb 2012 21:32:23 -0600
Brian Curtin wrote:
> While some effort has gone on to get the 32-bit build to compile
> without warnings (thanks for that!), 64-bit still has numerous
> warnings. Before I push forward on more of the VS2010 port, I'd like
> to have a clean 2008 build all around
Brett Cannon writes:
> I think that's inviting trouble if you can provide the seed. It leads to a
> false sense of security
I thought the point of providing the seed was for reproducability of
tests and the like?
As for "false sense", can't we document this and chalk up hubristic
behavior to "
> It seems to me that part of the point of the byte/string split (and the
> lack of automatic coercion) is to make the programmer be explicit about
> converting between unicode and bytes. Having these functions, which
> convert between binary formats (ASCII-only representations of binary data
> an
24 matches
Mail list logo
