New submission from Samuel Freilich :
_PyObject_FastCallDict and _PyObject_FastCallKeywords assert that there is no
pending exception before calling functions that might otherwise clobber the
exception state. However, that doesn't produce very clear output for debugging,
since the assert
New submission from Samuel Freilich :
Currently, it's an error to call the stop() method of a patcher object created
by mock.patch repeatedly:
>>> patch = mock.patch.object(Foo, 'BAR', 'x')
>>> patch.start()
'x'
>>> patch.stop()
>>> patch.stop()
RuntimeErr
Samuel Freilich added the comment:
Sure, but the bug in error-handling should still be fixed. Currently, if
_call_matcher returns an exception, that's ignored by assert_has_calls, and the
error message generated as a result is extremely misleading
Samuel Freilich added the comment:
This is still not totally fixed. This solves the underlying error with method
specs, but not the bug that was causing the error-swallowing in
assert_has_calls:
https://github.com/python/cpython/blob/ee536b2020b1f0baad1286dbd4345e13870324af/Lib/unittest
Change by Samuel Freilich :
--
pull_requests: +15630
pull_request: https://github.com/python/cpython/pull/16005
___
Python tracker
<https://bugs.python.org/issue36
Samuel Freilich added the comment:
Check out my PR, which solves a much smaller issue: It fixes a bug in the
exception raising logic in assert_has_calls (and _awaits) which makes
complicated problems like the one you mention much harder to debug.
Also it has tests
Change by Samuel Freilich :
--
keywords: +patch
pull_requests: +15942
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/16361
___
Python tracker
<https://bugs.python.org/issu
Samuel Freilich added the comment:
python-ideas thread:
https://mail.python.org/archives/list/python-id...@python.org/thread/B6OMGYIM47OVGOCZLEY3MEUJDFURJRDV/
The most minimal ideas from that seem to be:
1. Maybe link to the glossary from the error message (if links to documentation
Samuel Freilich added the comment:
> The user already knows
The example I link to in the initial description appears to be one case where
the user does not in fact know.
I do think context that this restriction applies to dict key in particular is
very relevant. The line could use the s
Samuel Freilich added the comment:
> No minor tweak to the exception message will make this go away. For
> understanding to occur, the only way to forward is to learn a bit about
> hashability. That is a step that every beginner must take.
This is a derisive and beginner-hostile
Samuel Freilich added the comment:
> I think it's reasonable to discuss the problem on python-ideas rather than on
> a bugs issue, when it's not obvious what the right solution is.
I did start a thread there. Don't object to that, if that's a better forum for
this sort of
New submission from Samuel Freilich :
Currently, if you (for example) put a dict as a value in a set or key in a
dict, you get:
TypeError: unhashable type: 'dict'
I'm pretty sure this wording goes back a long time, but I've noticed that
Python beginners tend to find this really confusing
Samuel Freilich added the comment:
> A modern solution for this is to define a singledispatch function (with
> implementations for your custom types) and pass it as the `default` parameter
> to the dump functions.
Does that work? I thought the default function only got called
Samuel Freilich added the comment:
I think the less-minor issue, of which this is a small subset, is that
JSONEncoder doesn't allow changing the behavior for default-serializable types
at all. That means you can't choose to lose less information in round-trip
serialization/deserialization
Samuel Freilich added the comment:
A fully general solution for this might require a separate way to override the
behavior for serializing dict keys (since those have to be serialized as
strings).
--
___
Python tracker
<https://bugs.python.
15 matches
Mail list logo
