Dustin Spicuzza added the comment:
FWIW, I've been using the patch in my PR and it seems to work.
--
___
Python tracker
<https://bugs.python.org/issue41
Change by Dustin Spicuzza :
--
keywords: +patch
pull_requests: +21530
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22525
___
Python tracker
<https://bugs.python.org/issu
New submission from Dustin Spicuzza :
I'm cross-compiling python to ARM, following instructions from the crossenv
project @
https://crossenv.readthedocs.io/en/latest/quickstart.html#build-or-obtain-host-python
I was getting pthread related errors when using cross-built extension modules.
I
Dustin Spicuzza <dus...@virtualroadside.com> added the comment:
Finally got around to looking at this.
# cat /proc/sys/kernel/random/entropy_avail
183
.. ran python3 -c 'import os; os.getrandom(1, flags=os.GRND_NONBLOCK)' a few
times, but didn't run into a hang. Seems like the entropy
Dustin Spicuzza <dus...@virtualroadside.com> added the comment:
I'm sure that the platform (a RT linux customized by National Instruments) has
issues related to urandom, as this has reared it's ugly head with other PEP 525
related issues also: https://bugs.python.org/issue29208
I'l
Change by Dustin Spicuzza <dus...@virtualroadside.com>:
--
keywords: +patch
pull_requests: +4745
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Dustin Spicuzza <dus...@virtualroadside.com> added the comment:
Because of backwards compatibility (despite a statement saying it's not
guaranteed for pathlib), I think the best approach would be to create a
'globmatch' function for PurePath instead of modifying the match fu
Dustin Spicuzza <dus...@virtualroadside.com> added the comment:
I just ran into this also. It seems like a very strange omission that match and
glob don't support the same patterns (and I'm surprised that they don't share
more code).
--
nosy: +vi
Changes by Dustin Spicuzza <dus...@virtualroadside.com>:
--
type: -> behavior
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Changes by Dustin Spicuzza <dus...@virtualroadside.com>:
--
title: compileall fails with urandom error even if number of workers is 1 ->
compileall hangs when accessing urandom even if number of workers is 1
___
Python tra
New submission from Dustin Spicuzza:
Found on Python 3.6 on a low-resource platform (NI RoboRIO), it seems that this
occurs only because the ProcessPoolExecutor is being imported. A proposed fix
would only import ProcessPoolExecutor if -j > 1. Stacktrace follows:
/usr/local/bin/python3
Dustin Spicuzza added the comment:
I'm able to confirm that the patch does indeed fix the problem. Thanks everyone!
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Dustin Spicuzza added the comment:
I'll try applying that fix tomorrow and see if the issue is addressed.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Dustin Spicuzza added the comment:
Crap, after reading more carefully, I see that PEP was rejected in favor of PEP
524.
According to that PEP, then I must implement the wait_for_system_rng()
function? It's a bit weird, because I'm not explicitly using the random module
and don't care to use
New submission from Dustin Spicuzza:
I haven't dug into this very deeply yet, so I'm seeking some clarity on this
issue before doing so.
According to my reading of PEP 522 (https://www.python.org/dev/peps/pep-0522/),
BlockingIOError will be raised in security sensitive APIs, but not when just
15 matches
Mail list logo
