Re: [Python-Dev] Stop using timeit, use perf.timeit!

On Sat, Jun 11, 2016 at 07:43:18PM -0400, Random832 wrote: > On Fri, Jun 10, 2016, at 21:45, Steven D'Aprano wrote: > > If you express your performances as speeds (as "calculations per > > second") then the harmonic mean is the right way to average them. > > That's true in so far as you get the

[Python-Dev] [RELEASE] Python 2.7.12 release candidate 1

Python 2.7.12 release candidate 1 is now available for download. This is a preview release of the next bugfix release in the Python 2.7.x series. Assuming no horrible regressions are located, a final release will follow in two weeks. Downloads for 2.7.12rc1 can be found python.org:

[Python-Dev] [RELEASED] Python 3.4.5rc1 and Python 3.5.2rc1 are now available

On behalf of the Python development community and the Python 3.4 and Python 3.5 release teams, I'm pleased to announce the availability of Python 3.4.5rc1 and Python 3.5.2rc1. Python 3.4 is now in "security fixes only" mode. This is the final stage of support for Python 3.4. All changes

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Sun, Jun 12, 2016 at 4:28 PM, Theodore Ts'o wrote: > P.S. BTW, I probably won't change the behaviour of /dev/urandom to > make it be blocking. Before I found out about Pyhton Bug #26839, I > actually had patches that did make /dev/urandom blocking, and they > were planned to

Re: [Python-Dev] Reminder: 3.6.0a2 snapshot 2016-06-13 12:00 UTC

On 06/10/2016 03:23 PM, Ned Deily wrote: Also note that Larry has announced plans to do a 3.5.2 release candidate sometime this weekend and Benjamin plans to do a 2.7.12 release candidate. So get important maintenance release fixes in ASAP. To clarify: /both/ 3.5.2rc1 /and/ 3.4.5rc1 were

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Sun, Jun 12, 2016 at 09:01:09PM +0100, Cory Benfield wrote: > My problem with /dev/urandom is that it’s a trap, lying in wait for > someone who doesn’t know enough about the problem they’re solving to > step into it. And my answer to that question is absent backwards compatibility concerns,

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Sun, Jun 12, 2016 at 11:07:22AM -0700, Nathaniel Smith wrote: > But for example, if a process is actively blocked waiting > for the initial entropy, one could spawn a kernel thread that keeps the > system from quiescing by attempting to scrounge up entropy as fast as > possible, via whatever

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

> On 12 Jun 2016, at 14:43, Theodore Ts'o wrote: > > Well, it can only happen on Linux because you insist on falling back > to /dev/urandom --- and because other OS's have the good taste not to > use systemd and/or Python very early in the boot process. If someone > tried to run

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Jun 11, 2016 11:13 PM, "Theodore Ts'o" wrote: > > On Sat, Jun 11, 2016 at 05:46:29PM -0400, Donald Stufft wrote: > > > > It was a RaspberryPI that ran a shell script on boot that called > > ssh-keygen. That shell script could have just as easily been a > > Python script that

Re: [Python-Dev] writing to /dev/*random [was: BDFL ruling request: should we block ...]

> On Jun 11, 2016, at 8:16 PM, Stephen J. Turnbull wrote: > > This fails for unprivileged users on Mac. I'm not sure what happens > on Linux; it appears to succeed, but the result wasn't what I > expected. I think that on Linux it will mix in whatever you write into the

Re: [Python-Dev] C99

Michael Felt felt.demon.nl> writes: > I am using IBM xlc aka vac - version 11. > > afaik it will deal with c99 features (by default I set it to behave that > way because a common 'issue' is C++ style comments, when they should not > be that style (fyi: not seen that in Python). We had a

Re: [Python-Dev] C99

I am using IBM xlc aka vac - version 11. afaik it will deal with c99 features (by default I set it to behave that way because a common 'issue' is C++ style comments, when they should not be that style (fyi: not seen that in Python). IMHO: GCC is not just a compiler - it brings with it a

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

On 2016-05-25 12:29, Christian Heimes wrote: > Hi everybody, > > I have three hashing-related patches for Python 3.6 that are waiting for > review. Altogether the three patches add ten new hash algorithms to the > hashlib module: SHA3 (224, 256, 384, 512), SHAKE (SHA3 XOF 128, 256), > BLAKE2

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Sun, Jun 12, 2016 at 11:40:58AM +0100, Cory Benfield wrote: > > Of this set, only cloud-init worries me, and it worries me for the > *opposite* reason that Guido and Larry are worried. Guido and Larry > are worried that programs like cloud-init will be delayed by two > minutes while they wait

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Sun, Jun 12, 2016 at 01:49:34AM -0400, Random832 wrote: > > The intention behind getrandom() is that it is intended *only* for > > cryptographic purposes. > > I'm somewhat confused now because if that's the case it seems to > accomplish multiple unrelated things. Why was this implemented as a

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 11 June 2016 at 22:46, Donald Stufft wrote: > I guess one question would be, what does the secrets module do if it’s on a > Linux that is too old to have getrandom(0), off the top of my head I can > think of: > > * Silently fall back to reading os.urandom and hope that it’s

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

> On 12 Jun 2016, at 07:11, Theodore Ts'o wrote: > > On Sat, Jun 11, 2016 at 05:46:29PM -0400, Donald Stufft wrote: >> >> It was a RaspberryPI that ran a shell script on boot that called >> ssh-keygen. That shell script could have just as easily been a >> Python script that

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Sat, Jun 11, 2016 at 05:46:29PM -0400, Donald Stufft wrote: > > It was a RaspberryPI that ran a shell script on boot that called > ssh-keygen. That shell script could have just as easily been a > Python script that called os.urandom via > https://github.com/sybrenstuvel/python-rsa instead of