CLN: fix all flake8 warnings in pandas/io #12096
Conversation
| @@ -101,7 +100,8 @@ class ParserWarning(Warning): | |||
| keep_default_na : bool, default True | |||
| If na_values are specified and keep_default_na is False the default NaN | |||
| values are overridden, otherwise they're appended to | |||
| parse_dates : boolean, list of ints or names, list of lists, or dict, default False | |||
| parse_dates : boolean, list of ints or names, list of lists, or dict, | |||
| default False | |||
There was a problem hiding this comment.
Same comment as in one of the previous rounds. This 'default False' on the new line will give non-ideal results in the html docs.
There was a problem hiding this comment.
This begs a general question: what to do with parameters that accept a ton of different types of input? I don't think we are doing users any favors by making a long line listing them all out; it would be better to have a bulleted list below the parameter name if that will render properly in the docs. Thoughts?
There was a problem hiding this comment.
I like this quite a bit. Many times, I find I spend quite a bit of time parsing the different possibilities.
There was a problem hiding this comment.
Yes, if the options are clearly listed below (as is already a bit the case, only the bullet symbols are missing), a shorter type description is certainly OK. Eg boolean, list or dict, default False is certainly sufficient (and short enough)
|
@jreback can you give me a thumbs up to merge if the build passes? |
|
or @jorisvandenbossche too. Nested lists in RST I think require the extra line break |
| num_format_str = self.datetime_format | ||
| elif isinstance(cell.val, datetime.date): |
There was a problem hiding this comment.
ok I guess. I just usually import datetime then directly reference this as IMHO it is more clear.
|
some minor comments. only issue is maybe we shouldn't touch.
|
|
I see; any harm in leaving them as is here or would you prefer I revert the changes? |
|
in theory your changes should be fine for just trying not to touch those until they are removed. |
|
@jreback I think we are not going to updat the ´io/data.py´ code anymore with changes that happen in pandas-datareader? (as we did in the beginning) If that is the case, I don't think there is any harm in leaving that file in here, otherwise I would say to revert (to more easily compare/update with pandas-datareader) |
|
@jorisvandenbossche no it won't be updated. Just trying to not change it. These pep changes won't hurt, as they are tested, so really no big deal. (bigger deal is |
| * dict | ||
|
|
||
| * {'foo' : [1, 3]} -> parse columns 1, 3 as date and call result 'foo' | ||
|
|
There was a problem hiding this comment.
Yes, as you say, in principle rst needs blank lines if you use a nested list (but I am not sure how this is actually handled in the docstrings, should test that).
But in this case, as trade-off between looking nice in html and in plain text, I would maybe go without the nesting of the lists? (as now it takes quite some space in the plaintext version). Something like:
* boolean: If True -> try parsing the index.
* list of ints or names: If [1, 2, 3] -> try parsing columns 1, 2, 3 each as a separate date
column.
* list of lists: If [[1, 3]] -> combine columns 1 and 3 and parse as a single date
column.
* dict: {'foo' : [1, 3]} -> parse columns 1, 3 as date and call result 'foo'
|
OK, I unstaged the ga/wb/data changes and cleaned up the parse_dates bit of the docstring. Will merge once the build passes |
I suppressed warnings in test_parsers.py because of the amount of literal strings in the file.