Bert JW Regeer added the comment:
Ned: You are correct, I hadn't even considered that as a potential issue. Added
a context to grab the fork multiprocessing context and we are back to the speed
it was before.
This slowdown is pretty huge for just changing the way the process is forked
New submission from Bert JW Regeer :
I am being fairly vague here, but it is mainly because I don't know the best
way to reduce the test cases down to pinpoint the problem.
I maintain Waitress, a pure Python HTTP server, and ever since Python 3.8
there's been a marked slowdown
Change by Bert JW Regeer :
--
nosy: +Bert JW Regeer
___
Python tracker
<https://bugs.python.org/issue30717>
___
___
Python-bugs-list mailing list
Unsubscribe:
Bert JW Regeer added the comment:
I'll take a look and see if I can get the other fixes from WebOb and add them
to a patch, and create a follow-up PR.
If I can stop carrying a monkey patch for the standard library I am all for it!
Thanks for running with this!
--
nosy: +Bert JW
Change by Bert JW Regeer <ber...@regeer.org>:
--
nosy: +X-Istence
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue4963>
___
__
New submission from Bert JW Regeer <ber...@regeer.org>:
doctest fails to consider `\r\n` as a blank line.
--
components: Library (Lib)
files: test.py
messages: 306595
nosy: X-Istence
priority: normal
severity: normal
status: open
title: doctest does not consider \r\n a
versions:
Bert JW Regeer added the comment:
Unfortunately I need to spin another patch, the one I created didn't solve the
issue for one of WebOb's users:
https://github.com/Pylons/webob/pull/300 (Thanks Julien Meyer!)
I have his permission to grab his test/patch and update this patch, I will get
Bert JW Regeer added the comment:
I've uploaded a patchset to bug #2 that fixes this issue by fixing
make_file, and doesn't cause Python to throw out the content-length information.
It also fixes FieldStorage for when you provide it a non-multipart form
submission and there is no list
Bert JW Regeer added the comment:
@berker.peksag:
Attached is a patch with a test case that exercises this issue.
Code path is that read_single() checks if the length is greater than 0, and
then it reads binary, otherwise it reads it as a single line. This fixes
make_file so
Bert JW Regeer added the comment:
Here's a dump from Python 3.6:
b'PK\x03\x04\x14\x00\x08\x00\x00\x00\xc0~pI\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x10\x00\x00\x00zinfo_or_arcnamefoo!es\x8c\x03\x00\x00\x00\x03\x00\x00\x00PK\x01\x02\x14\x03\x14\x00\x08\x00\x00\x00\xc0~pI!es\x8c\x03\x00
Bert JW Regeer added the comment:
It's literally the string written:
writer.writestr('zinfo_or_arcname', b'foo')
rbo in this case is a simple file like object.
I can get dumps from Python 3.5 and Python 3.6 if necessary.
--
___
Python tracker <
New submission from Bert JW Regeer:
I am the current maintainer of WebOb, and noticed that on Python 3.6 and 3.7 I
noticed that a test started failing.
Granted, the test is checking the size of the file created and it is not the
brightest idea in a test, but it's been stable since Python 2.5
Bert JW Regeer added the comment:
Updated versions this applies to.
--
versions: +Python 3.3, Python 3.4, Python 3.6, Python 3.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Bert JW Regeer <ber...@regeer.org>:
--
nosy: +berker.peksag
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue2>
___
_
Bert JW Regeer added the comment:
On line #890 in self.make_file() the check for _binary_file should be changed
to also check for self.length >= 0.
https://github.com/python/cpython/blob/3.4/Lib/cgi.py#L890
becomes:
if self._binary_file or self.length >= 0:
_binary_file is only ev
Bert JW Regeer added the comment:
This is not a duplicate of https://bugs.python.org/issue24764
--
nosy: +X-Istence
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Bert JW Regeer added the comment:
This is still very much an issue, and makes it more difficult to write generic
python request/response libraries because we can't assume that a read() will
return, and relying on the Content-Length being set is not always possible
unfortunately
JW added the comment:
please find attached the reproducer C.7z
this issue only happens with this format of data before and after the difference
--
Added file: http://bugs.python.org/file44046/C.7z
___
Python tracker <rep...@bugs.python.org>
JW added the comment:
i found that making a change similar to this one in a certain place towards
then end of my 300 or so long list of strings produces issues further along:
making a change of Latitude=1.1 -> Latitude=111.1 correctly shows as 11 added;
however subsequent matching li
New submission from Bert JW Regeer:
One of the changes in Python 3.5's traceback functionality broke existing code
compared to Python 3.4 by injecting an extra stack frame into the list when
using traceback.extract_stack:
What this looks like on Python 3.5:
pyramid/tests/test_config
Bert JW Regeer added the comment:
Looks like this is a dup of: https://bugs.python.org/issue25108
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Bert JW Regeer ber...@regeer.org added the comment:
In my first comment on this bug post I posted what project has issues with
this, Botan with Boost.Python on FreeBSD and Mac OS X.
If required I will post how to reproduce this error using that project. If you
would prefer a simplified test
New submission from Bert JW Regeer ber...@regeer.org:
I was recently attempting to get Botan (http://botan.randombit.net) working
with Python 2.6.6 on FreeBSD when it failed to compile, I filled a bug with
Botan (http://bugs.randombit.net/show_bug.cgi?id=135) and first thought
23 matches
Mail list logo
