CLN: Exception in core.dtypes #28387
Conversation
|
I can't duplicate the black complaints on Mac or Linux, both with 19.3b0 |
|
lgtm. merge pending CI updates. |
|
Just a guess but is it the double quote escaping that black doesn't like? Seems like 4 files failed and that's done in 4 files. Maybe single quotes for the outer string I think black mostly tries to avoid backslash escaping: |
|
That seems to fix it, thanks @WillAyd |
| @@ -67,7 +67,7 @@ def test_astype_cannot_cast(self, index, dtype): | |||
| index.astype(dtype) | |||
|
|
|||
| def test_astype_invalid_dtype(self, index): | |||
| msg = "data type 'fake_dtype' not understood" | |||
| msg = 'data type "fake_dtype" not understood' | |||
There was a problem hiding this comment.
Do we need to change the quoting here? I'm actually surprised this doesn't cause failures since the exception message shown in diff uses single quotes around the bad dtype
There was a problem hiding this comment.
this is now passing through an exception raised by numpy
| if not isinstance(dtype, str): | ||
| raise TypeError("data type not understood") | ||
| except SyntaxError: | ||
| # np.dtype uses `eval` which can raise SyntaxError |
There was a problem hiding this comment.
You can easily end up here with something that does not raise a syntaxError
But I assume the idea is that in that case the TypeError generated by numpy is fine to raise directly?
If so, can you add a comment for that?
There was a problem hiding this comment.
(based on your comment below, I suppose that is indeed the case)
There was a problem hiding this comment.
@jorisvandenbossche I am not sure it matters; this will raise a TypeError if its invalid anyhow (catching the SyntaxError is just for hygiene of the error message)
|
lgtm. @WillAyd if you had comments. |
|
Thanks @jbrockmendel |
No description provided.