[issue35907] [security][CVE-2019-9948] Unnecessary URL scheme exists to allow local_file:// reading file in urllib
Petter S added the comment:
We should whitelist the protocols. The current solution with `getattr` is
really fragile.
For example, this crashes with a `TypeError`:
`URLopener().open("unknown_proxy://test")`
--
nosy: +Petter S
___
Python tracker
<https://bugs.python.org/issue35907>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35907] [security][CVE-2019-9948] Unnecessary URL scheme exists to allow local_file:// reading file in urllib
Petter S added the comment: The solution is incomplete because it fixes just this single security issue, not the inherent fragility of this file. If, in the future someone happens to add another method starting with open to this class, we are at risk of having the same problem again. As for the error message, it is of course a minor issue, but I don't think it is expected that "unknown_proxy://" and "something_else://" raise different exceptions, right? -- ___ Python tracker <https://bugs.python.org/issue35907> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40673] UrlOpener raises different exceptions based on implementation detail
New submission from Petter S :
The following code crashes with TypeError:
URLopener().open("unknown_proxy://test")
the expected behavior is an OSError, which is normally raised for unknown
protocols.
This implementation of directly calling a method called "unknown_proxy" is
fragile and was recently the subject of a security issue:
https://bugs.python.org/issue35907 (CVE-2019-9948)
Would be good to make this more robust.
--
components: Library (Lib)
messages: 369291
nosy: Petter S
priority: normal
severity: normal
status: open
title: UrlOpener raises different exceptions based on implementation detail
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue40673>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40673] urllib.request.URLopener raises different exceptions based on implementation detail
Change by Petter S : -- title: UrlOpener raises different exceptions based on implementation detail -> urllib.request.URLopener raises different exceptions based on implementation detail ___ Python tracker <https://bugs.python.org/issue40673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35907] [security][CVE-2019-9948] Unnecessary URL scheme exists to allow local_file:// reading file in urllib
Petter S added the comment: OK: https://bugs.python.org/issue40673 -- ___ Python tracker <https://bugs.python.org/issue35907> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40673] urllib.request.URLopener raises different exceptions based on implementation detail
Petter S added the comment: I can fix this, but it does not have high priority. -- ___ Python tracker <https://bugs.python.org/issue40673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40673] urllib.request.URLopener raises different exceptions based on implementation detail
Petter S added the comment: I see. Perhaps that is the resolution then. -- ___ Python tracker <https://bugs.python.org/issue40673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35047] Better error messages in unittest.mock
Change by Petter S : -- pull_requests: +13628 pull_request: https://github.com/python/cpython/pull/13746 ___ Python tracker <https://bugs.python.org/issue35047> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27682] wsgiref BaseHandler / SimpleHandler can raise additional errors when handling an error
Change by Petter S : -- pull_requests: +13630 pull_request: https://github.com/python/cpython/pull/13748 ___ Python tracker <https://bugs.python.org/issue27682> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27682] wsgiref BaseHandler / SimpleHandler can raise additional errors when handling an error
Petter S added the comment:
The following message can still appear in the log when running the Django
development server:
Exception happened during processing of request from ('127.0.0.1', 50713)
Traceback (most recent call last):
File "d:\python37\Lib\socketserver.py", line 650, in process_request_thread
self.finish_request(request, client_address)
File "d:\python37\Lib\socketserver.py", line 360, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "d:\python37\Lib\socketserver.py", line 720, in __init__
self.handle()
File "D:\Virtualenvs\***\lib\site-packages\django\core\servers\basehttp.py",
line 171, in handle
self.handle_one_request()
File "D:\Virtualenvs\***\lib\site-packages\django\core\servers\basehttp.py",
line 179, in handle_one_request
self.raw_requestline = self.rfile.readline(65537)
File "d:\python37\Lib\socket.py", line 589, in readinto
return self._sock.recv_into(b)
ConnectionAbortedError: [WinError 10053] An established connection was aborted
by the software in your host machine
This is much better than before but even this message is completely
uninteresting as web browsers disconnect from servers all the time. However,
this could be better to fix in Django.
--
___
Python tracker
<https://bugs.python.org/issue27682>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27682] wsgiref BaseHandler / SimpleHandler can raise additional errors when handling an error
Petter S added the comment: Could potentially already be fixed in Django: https://github.com/django/django/commit/7785e03ba89aafbd949191f126361fb9103cb980#diff-f6d1c75ec606389da5af6558bf57f171L51 -- ___ Python tracker <https://bugs.python.org/issue27682> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27682] wsgiref BaseHandler / SimpleHandler can raise additional errors when handling an error
Petter S added the comment: No it is not fixed in Django, but I verified that adding ConnectionAbortedError on this line https://github.com/django/django/blob/c6581a40be3bb4c1e13861f0adbb3fe01f09107f/django/core/servers/basehttp.py#L55 fixes the error. -- ___ Python tracker <https://bugs.python.org/issue27682> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35656] More matchers in unittest.mock
New submission from Petter S :
The ``ANY`` object in ``unittest.mock`` is also pretty useful when verifying
dicts in tests:
self.assertEqual(result, {
"message": "Hi!",
"code": 0,
"id": mock.ANY
})
Then it does not matter what the (presumably randomly generated) id is. For the
same use cases, objects like ``APPROXIMATE`` (for approximate floating-point
matching) and ``MATCHES`` (taking a boolean lambda) would be pretty useful, I
think.
--
components: Library (Lib)
messages: 332968
nosy: Petter S
priority: normal
severity: normal
status: open
title: More matchers in unittest.mock
type: enhancement
___
Python tracker
<https://bugs.python.org/issue35656>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35656] More matchers in unittest.mock
Petter S added the comment:
Yes, something like this:
class APPROXIMATE:
"""Takes a floating point number and implements approximate equality."""
def __init__(self, value):
self.value = value
def __eq__(self, other):
return abs(self.value - other) / (abs(self.value) + abs(other)) <
1e-6
def __repr__(self):
return f"APPROXIMATE({self.value})"
Then the following would hold:
got = {
"name": "Petter",
"length": 1.91
}
expected = {
"name": "Petter",
"length": APPROXIMATE(1.9)
}
assert got == expected
But not
got["length"] = 1.8
assert got == expected
--
___
Python tracker
<https://bugs.python.org/issue35656>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35656] More matchers in unittest.mock
Petter S added the comment: Agreed! The code above was a quick example. There are also functions in the standard library for approximate float matching that the "real" code would use. -- ___ Python tracker <https://bugs.python.org/issue35656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35656] More matchers in unittest.mock
Petter S added the comment: I am of the opposite opinion. :-) > if I know roughly what the float should be why would I not want to test it > for exactness? When testing algorithms, it is often the case that the answer should be mathematically exactly 2, but due to floating-point inexactness it becomes, say, 1.97 in practice. If I then test for exactly 1.97 the test becomes very brittle and sensitive for e.g. order of multiplications. Testing floating point numbers with a relative error is essential in many application. -- ___ Python tracker <https://bugs.python.org/issue35656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27682] wsgiref BaseHandler / SimpleHandler can raise additional errors when handling an error
Petter S added the comment: The pull request solves this problem, but the discussion over there is really slow. -- ___ Python tracker <https://bugs.python.org/issue27682> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32992] unittest: Automatically run coroutines in a loop
Change by Petter S : -- keywords: +patch pull_requests: +5770 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue32992> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32972] unittest.TestCase coroutine support
Petter S added the comment: It's good to see others with the same idea as me. I just wrote https://github.com/python/cpython/pull/6005/commits/4d7e1837f235687c875e985e97701609fc1ac458 . In my opinion, there is no need for another test class. I completely agree with Zachary Ware that the current TestCase class is more or less broken (or at least easily misused) with respect to coroutines. Fixing TestCase would not break existing code. The customization of event loop would not be hard to add. -- nosy: +Petter S ___ Python tracker <https://bugs.python.org/issue32972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32972] unittest.TestCase coroutine support
Petter S added the comment: > Also, I personally subclassed TestCase in many of my projects specifically to > add async support. To do that you have to use a metaclass to scan class' > namespace for 'async def' functions. Doesn't that break when, for example, test methods are decorated with unittest.mock.patch? -- ___ Python tracker <https://bugs.python.org/issue32972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32972] unittest.TestCase coroutine support
Petter S added the comment: > No, it shouldn't break them if you wrap async methods carefully. > Here's a metaclass that I wrote recently doing just that That code does not seem to work for me: https://gist.github.com/PetterS/f684095a09fd1d8164a4d8b28ce3932d I get "RuntimeWarning: coroutine 'test_async_with_mock' was never awaited" @mock.patch needs to work correctly for test methods. >> I'm really not seeing what a separate class buys you. > I already mentioned in my previous comments that adding async support to > unittest.TestCase would require us to add a metaclass to it, which is > potentially a backwards incompatible change. No, unittest.TestCase can handle this, as demonstrated by two PRs in this bug. This would not change the behavior of existing (working) code. -- ___ Python tracker <https://bugs.python.org/issue32972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32972] unittest.TestCase coroutine support
Petter S added the comment: > 1. Do we need support for async versions of setUp, setUpClass, etc? In my > opinion: yes. I completely agree. I would imagine many or most real-world tests requiring async setUp. There is also the question on how a custom loop etc. can be used in the unit test class. How about this: unittest.TestCase gets a very small refactor in which a overridable helper method is used to run the test method. This helper method can then be changed to run async methods in a subclass AsyncioTestCase (that probably should live in asyncio). Pull request 6005 contained such a helper method, but the async part could be implemented in the subclass instead. -- ___ Python tracker <https://bugs.python.org/issue32972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32972] unittest.TestCase coroutine support
Change by Petter S : -- keywords: +patch pull_requests: +5812 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue32972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32972] unittest.TestCase coroutine support
Petter S added the comment: John: inspect.iscoroutinefunction(meth) does not work if the method is decorated with e.g. unittest.mock.patch. -- ___ Python tracker <https://bugs.python.org/issue32972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32972] unittest.TestCase coroutine support
Petter S added the comment: Personally, I think John's PR is fine. (but the test class could arguably live in asyncio) I like that setUp, tearDown and test methods all can be async. But if setUp and tearDown should never be async as Yury commented above, they don't need runners. That is what I went for in my PR. Introducing three new public methods to TestCase is too much. I originally made the runner private, but Yury told me to make it public and document it. -- ___ Python tracker <https://bugs.python.org/issue32972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25155] Windows: datetime.datetime.now() raises an OverflowError for date after year 2038
Petter S added the comment: For Python 3: $ python3 --version Python 3.7.0b3 $ python3 Fatal Python error: _Py_InitializeMainInterpreter: can't initialize time OverflowError: timestamp too large to convert to C _PyTime_t Current thread 0x7f0232c21080 (most recent call first): Aborted (core dumped) -- ___ Python tracker <https://bugs.python.org/issue25155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25155] Windows: datetime.datetime.now() raises an OverflowError for date after year 2038
Petter S added the comment: I get this error when starting the interpreter in Windows subsystem for Linux (WSL). I am using Python 2.7.15rc1 $ python --version Python 2.7.15rc1 $ python Fatal Python error: _Py_InitializeMainInterpreter: can't initialize time OverflowError: timestamp too large to convert to C _PyTime_t Current thread 0x7fe547231080 (most recent call first): Aborted (core dumped) -- nosy: +Petter S versions: +Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue25155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25155] Windows: datetime.datetime.now() raises an OverflowError for date after year 2038
Petter S added the comment: I also compiled Python myself on WSL. The bug seemed to appear after computer had been running for a while. Before that, the interpreters were working normally. And after rebooting the problem disappeared. -- ___ Python tracker <https://bugs.python.org/issue25155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33965] [Windows WSL] Fatal Python error: _Py_InitializeMainInterpreter: can't initialize time, after year 2038
Petter S added the comment: Makes sense. I fail to reproduce it myself. :-( -- ___ Python tracker <https://bugs.python.org/issue33965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33965] [Windows WSL] Fatal Python error: _Py_InitializeMainInterpreter: can't initialize time, after year 2038
Petter S added the comment: I am updating this bug since someone may find it. The problem lies with WSL. After having my computer running for many days, this is the result of the uptime command: $ uptime 11:23:19 up -24855 days, -3:-14, 0 users, load average: 0.52, 0.58, 0.59 Restarting the computer fixes this and the Python issue discussed in this thread. -- ___ Python tracker <https://bugs.python.org/issue33965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34547] Wsgiref server does not handle closed connections gracefully
New submission from Petter S :
The server in the wsgiref module is actually used a lot. For example, it is the
server Django uses for development.
A very common thing that happens during Django development is that the web
browser closes the connection for some reason. Then very long stack traces
appear in the Django logs:
[30/Aug/2018 12:10:38] "POST /login/ HTTP/1.1" 200 3964
Traceback (most recent call last):
File "d:\python37\Lib\wsgiref\handlers.py", line 138, in run
self.finish_response()
File "d:\python37\Lib\wsgiref\handlers.py", line 180, in finish_response
self.write(data)
File "d:\python37\Lib\wsgiref\handlers.py", line 274, in write
self.send_headers()
File "d:\python37\Lib\wsgiref\handlers.py", line 332, in send_headers
self.send_preamble()
File "d:\python37\Lib\wsgiref\handlers.py", line 255, in send_preamble
('Date: %s\r\n' % format_date_time(time.time())).encode('iso-8859-1')
File "d:\python37\Lib\wsgiref\handlers.py", line 453, in _write
result = self.stdout.write(data)
File "d:\python37\Lib\socketserver.py", line 796, in write
self._sock.sendall(b)
ConnectionAbortedError: [WinError 10053] An established connection was
aborted by the software in your host machine
[30/Aug/2018 12:10:38] "POST /login/ HTTP/1.1" 500 59
Exception happened during processing of request from ('127.0.0.1', 50112)
Traceback (most recent call last):
File "d:\python37\Lib\wsgiref\handlers.py", line 138, in run
self.finish_response()
File "d:\python37\Lib\wsgiref\handlers.py", line 180, in finish_response
self.write(data)
File "d:\python37\Lib\wsgiref\handlers.py", line 274, in write
self.send_headers()
File "d:\python37\Lib\wsgiref\handlers.py", line 332, in send_headers
self.send_preamble()
File "d:\python37\Lib\wsgiref\handlers.py", line 255, in send_preamble
('Date: %s\r\n' % format_date_time(time.time())).encode('iso-8859-1')
File "d:\python37\Lib\wsgiref\handlers.py", line 453, in _write
result = self.stdout.write(data)
File "d:\python37\Lib\socketserver.py", line 796, in write
self._sock.sendall(b)
ConnectionAbortedError: [WinError 10053] An established connection was
aborted by the software in your host machine
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "d:\python37\Lib\wsgiref\handlers.py", line 141, in run
self.handle_error()
File
"D:\Virtualenvs\ledev-X6wd5Q8f\lib\site-packages\django\core\servers\basehttp.py",
line 86, in handle_error
super().handle_error()
File "d:\python37\Lib\wsgiref\handlers.py", line 368, in handle_error
self.finish_response()
File "d:\python37\Lib\wsgiref\handlers.py", line 180, in finish_response
self.write(data)
File "d:\python37\Lib\wsgiref\handlers.py", line 274, in write
self.send_headers()
File "d:\python37\Lib\wsgiref\handlers.py", line 331, in send_headers
if not self.origin_server or self.client_is_modern():
File "d:\python37\Lib\wsgiref\handlers.py", line 344, in client_is_modern
return self.environ['SERVER_PROTOCOL'].upper() != 'HTTP/0.9'
TypeError: 'NoneType' object is not subscriptable
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "d:\python37\Lib\socketserver.py", line 647, in
process_request_thread
self.finish_request(request, client_address)
File "d:\python37\Lib\socketserver.py", line 357, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "d:\python37\Lib\socketserver.py", line 717, in __init__
self.handle()
File
"D:\Virtualenvs\ledev-X6wd5Q8f\lib\site-packages\django\core\servers\basehttp.py",
line 154, in handle
handler.run(self.server.get_app())
File "d:\python37\Lib\wsgiref\handlers.py", line 144, in run
self.close()
File "d:\python37\Lib\wsgiref\simple_server.py", line 35, in close
self.status.split(' ',1)[0], self.bytes_sent
AttributeError: 'NoneType' object has no attribute 'split'
Obviously, this is a bit annoying when developing with Django daily. Since
Django simply uses the wsgiref server, I though the best solution was to handle
closed connections more gracefully there.
I
[issue34547] Wsgiref server does not handle closed connections gracefully
Change by Petter S : -- type: -> enhancement ___ Python tracker <https://bugs.python.org/issue34547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34547] Wsgiref server does not handle closed connections gracefully
Change by Petter S : -- keywords: +patch pull_requests: +9096 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27682] wsgiref: Windows Error 10053, ConnectionAbortedError: [WinError 10053] An established connection was aborted by the software in your host machine
Petter S added the comment: The Github pull request https://github.com/python/cpython/pull/9713 addresses this. -- nosy: +Petter S ___ Python tracker <https://bugs.python.org/issue27682> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35047] Better error messages un unittest.mock
New submission from Petter S : When developing unit tests with `unittest.mock`, it is common to see error messages like this: AssertionError: Expected 'info' to not have been called. Called 3 times. It would be really helpful if those 3 calls were listed in the assertion error. I am happy to add this if people agree it is a good thing. -- components: Library (Lib) messages: 328292 nosy: Petter S priority: normal severity: normal status: open title: Better error messages un unittest.mock versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue35047> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35047] Better error messages in unittest.mock
Petter S added the comment:
Sure, consider the following code:
from unittest import mock
m = mock.Mock()
m(1, 3)
m("Test", data=[42])
When I call
m.assert_not_called()
I get the following error message:
AssertionError: Expected 'mock' to not have been called. Called 2 times.
This is what I would like to improve. On the other hand, if I call
m.assert_has_calls(mock.call(3))
I get the following error:
AssertionError: Calls not found.
Expected: ['', (3,), {}]
Actual: [call(1, 3), call('Test', data=[42])]
This is great and may serve as a template for what I want to introduce.
--
___
Python tracker
<https://bugs.python.org/issue35047>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35047] Better error messages in unittest.mock
Petter S added the comment: (The example above should have been "m.assert_has_calls([mock.call(3)])" but it does not affect my point.) -- ___ Python tracker <https://bugs.python.org/issue35047> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34547] Wsgiref server does not handle closed connections gracefully
Change by Petter S : -- pull_requests: +9419 ___ Python tracker <https://bugs.python.org/issue34547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35047] Better error messages in unittest.mock
Change by Petter S : -- keywords: +patch pull_requests: +9420 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35047> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34547] Wsgiref server does not handle closed connections gracefully
Change by Petter S : -- pull_requests: -9419 ___ Python tracker <https://bugs.python.org/issue34547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34547] Wsgiref server does not handle closed connections gracefully
Change by Petter S : -- pull_requests: +9437, 9438 ___ Python tracker <https://bugs.python.org/issue34547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34547] Wsgiref server does not handle closed connections gracefully
Change by Petter S : -- pull_requests: +9437 ___ Python tracker <https://bugs.python.org/issue34547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34547] Wsgiref server does not handle closed connections gracefully
Change by Petter S : -- pull_requests: -9437 ___ Python tracker <https://bugs.python.org/issue34547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34547] Wsgiref server does not handle closed connections gracefully
Change by Petter S : -- pull_requests: -9438 ___ Python tracker <https://bugs.python.org/issue34547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34547] Wsgiref server does not handle closed connections gracefully
Change by Petter S : -- pull_requests: +9475 ___ Python tracker <https://bugs.python.org/issue34547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32972] unittest.TestCase coroutine support
Petter S added the comment: As far as I am concerned, the discussion can continue in this issue. I still think a reasonable first step is to add a run hook to the regular TestCase class, like in PR 6051. But building consensus is a bit tricky. -- ___ Python tracker <https://bugs.python.org/issue32972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27682] wsgiref BaseHandler / SimpleHandler can raise additional errors when handling an error
Change by Petter S : -- keywords: +patch pull_requests: +9624 stage: test needed -> patch review ___ Python tracker <https://bugs.python.org/issue27682> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27682] wsgiref BaseHandler / SimpleHandler can raise additional errors when handling an error
Petter S added the comment: > I think this is what Petter is trying to do in > <https://github.com/python/cpython/pull/9713>. That's right. -- ___ Python tracker <https://bugs.python.org/issue27682> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
