Petter S added the comment:
I see. Perhaps that is the resolution then.
--
___
Python tracker
<https://bugs.python.org/issue40673>
___
___
Python-bugs-list m
Petter S added the comment:
I can fix this, but it does not have high priority.
--
___
Python tracker
<https://bugs.python.org/issue40673>
___
___
Python-bug
Petter S added the comment:
OK: https://bugs.python.org/issue40673
--
___
Python tracker
<https://bugs.python.org/issue35907>
___
___
Python-bugs-list mailin
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/issu
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"
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
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
___
Pyth
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
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.
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 &q
Change by Petter S :
--
pull_requests: +13630
pull_request: https://github.com/python/cpython/pull/13748
___
Python tracker
<https://bugs.python.org/issue27
Change by Petter S :
--
pull_requests: +13628
pull_request: https://github.com/python/cpython/pull/13746
___
Python tracker
<https://bugs.python.org/issue35
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/issue27
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
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.o
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):
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
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.p
Change by Petter S :
--
keywords: +patch
pull_requests: +9624
stage: test needed -> patch review
___
Python tracker
<https://bugs.python.org/issue27682>
___
_
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
Change by Petter S :
--
pull_requests: +9475
___
Python tracker
<https://bugs.python.org/issue34547>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Petter S :
--
pull_requests: -9438
___
Python tracker
<https://bugs.python.org/issue34547>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Petter S :
--
pull_requests: -9437
___
Python tracker
<https://bugs.python.org/issue34547>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Petter S :
--
pull_requests: +9437
___
Python tracker
<https://bugs.python.org/issue34547>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Petter S :
--
pull_requests: +9437, 9438
___
Python tracker
<https://bugs.python.org/issue34547>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Petter S :
--
pull_requests: -9419
___
Python tracker
<https://bugs.python.org/issue34547>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Petter S :
--
keywords: +patch
pull_requests: +9420
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35047>
___
___
Python-
Change by Petter S :
--
pull_requests: +9419
___
Python tracker
<https://bugs.python.org/issue34547>
___
___
Python-bugs-list mailing list
Unsubscribe:
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.o
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. Call
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 er
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/issue27
Change by Petter S :
--
keywords: +patch
pull_requests: +9096
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34547>
___
___
Python-
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
Change by Petter S :
--
type: -> enhancement
___
Python tracker
<https://bugs.python.org/issue34547>
___
___
Python-bugs-list mailing list
Unsubscrib
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
Petter S added the comment:
Makes sense. I fail to reproduce it myself. :-(
--
___
Python tracker
<https://bugs.python.org/issue33965>
___
___
Python-bugs-list m
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
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
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):
Ab
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. Th
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/issue32
Change by Petter S :
--
keywords: +patch
pull_requests: +5812
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32972>
___
___
Python-
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 uni
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 "Runt
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, te
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 tha
Change by Petter S :
--
keywords: +patch
pull_requests: +5770
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32992>
___
___
Python-
48 matches
Mail list logo
