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.
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/deser
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
in
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 for
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:
> 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
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 t
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:
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
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 misle
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:
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
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()
&
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 a
15 matches
Mail list logo
