[issue34173] [3.7] deadlock in /usr/lib/python3.7/concurrent/futures/thread.py

2019-01-07 Thread Corey Bryant
Corey Bryant added the comment: I think we can close this issue. It was narrowed down to eventlet. Please see: https://github.com/eventlet/eventlet/issues/508 On Tue, Jul 24, 2018 at 1:54 PM Karthikeyan Singaravelan < rep...@bugs.python.org> wrote: > > Karthikeyan Singaravela

[issue34173] [3.7] deadlock in /usr/lib/python3.7/concurrent/futures/thread.py

2018-07-24 Thread Corey Bryant
Change by Corey Bryant : -- title: [3.7] possible race condition in /usr/lib/python3.7/concurrent/futures/thread.py -> [3.7] deadlock in /usr/lib/python3.7/concurrent/futures/thread.py ___ Python tracker <https://bugs.python.org/issu

[issue34173] [3.7] possible race condition in /usr/lib/python3.7/concurrent/futures/thread.py

2018-07-24 Thread Corey Bryant
Corey Bryant added the comment: eventlet issue opened at: https://github.com/eventlet/eventlet/issues/508 -- ___ Python tracker <https://bugs.python.org/issue34

[issue34173] [3.7] possible race condition in /usr/lib/python3.7/concurrent/futures/thread.py

2018-07-24 Thread Corey Bryant
Corey Bryant added the comment: I've narrowed this down a bit more. It appears to be caused by eventlet patching of standard library thread modules. See new attached patch bp034173-recreate.py. I'll get a bug opened against eventlet. -- Added file: https://bugs.python.org

[issue34173] [3.7] possible race condition in /usr/lib/python3.7/concurrent/futures/thread.py

2018-07-24 Thread Corey Bryant
Corey Bryant added the comment: Karthikeyan, thanks for taking a look. I'm also unable to recreate with your test. I'm not sure what the difference is. I'll report back if I can figure it out. -- ___ Python tracker <https

[issue34173] [3.7] possible race condition in /usr/lib/python3.7/concurrent/futures/thread.py

2018-07-20 Thread Corey Bryant
New submission from Corey Bryant : I initially reported this on launchpad at https://bugs.launchpad.net/bugs/1782647. I'm running a test for a project that hangs and requires a Control-C to cancel it. The results look like this: https://paste.ubuntu.com/p/SwXsCcghjt/ In narrowing do

[issue18020] html.escape 10x slower than cgi.escape

2013-05-20 Thread Matt Bryant
Matt Bryant added the comment: I did a few more tests and am seeing the same speed differences Florent noticed. It seems reasonable to use .replace() instead, as it does the same thing significantly faster. I've attached a patch doing just this. -- keywords: +patch nosy: +Teh

[issue17083] can't specify newline string for readline for binary files

2013-02-01 Thread Bryant
Bryant added the comment: While my original description of this issue discussed arbitrary strings, I'd like to limit the scope of this issue down to just supporting the newline parameter to builtin.open() for binary files, just as it's supported for regular files. This adds n

[issue17083] can't specify newline string for readline for binary files

2013-01-30 Thread Bryant
Bryant added the comment: I'm not terribly worried about the "right" way for me to deal with my code, but that Python, in this instance, is inconsistent. While it doesn't want you to apply the concept of a "line" to a binary file in that it prevents you from spe

[issue17083] can't specify newline string for readline for binary files

2013-01-30 Thread Bryant
New submission from Bryant: When opening binary files in Python 3, the newline parameter cannot be set. While this kind of makes sense, readline() can still be used on binary files. This is great for my usage, but it is doing universal newline mode, I believe, so that any \r, \n, or \r\n