-
-
Notifications
You must be signed in to change notification settings - Fork 18.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DEPR, DOC: Deprecate buffer_lines in read_csv #13360
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -227,14 +227,19 @@ | |
Note that the entire file is read into a single DataFrame regardless, | ||
use the `chunksize` or `iterator` parameter to return the data in chunks. | ||
(Only valid with C parser) | ||
buffer_lines : int, default None | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. is this even used at all now? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. it seems its not respected at all now. so we should just remove this argument (or raise if its not There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Based on my PR description, nowhere. How significant of an API change would either option be? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. well it doesn't do anything now. I guess deprecation is fine. Why don't you re-word to say it currently has no-effect. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fair enough. Done. |
||
DEPRECATED: this argument will be removed in a future version because its | ||
value is not respected by the parser | ||
|
||
If low_memory is True, specify the number of rows to be read for each | ||
chunk. (Only valid with C parser) | ||
compact_ints : boolean, default False | ||
DEPRECATED: this argument will be removed in a future version | ||
|
||
If compact_ints is True, then for any column that is of integer dtype, | ||
the parser will attempt to cast it as the smallest integer dtype possible, | ||
either signed or unsigned depending on the specification from the | ||
`use_unsigned` parameter. | ||
|
||
use_unsigned : boolean, default False | ||
DEPRECATED: this argument will be removed in a future version | ||
|
||
|
@@ -448,6 +453,7 @@ def _read(filepath_or_buffer, kwds): | |
'float_precision', | ||
]) | ||
_deprecated_args = set([ | ||
'buffer_lines', | ||
'compact_ints', | ||
'use_unsigned', | ||
]) | ||
|
@@ -806,7 +812,8 @@ def _clean_options(self, options, engine): | |
_validate_header_arg(options['header']) | ||
|
||
for arg in _deprecated_args: | ||
if result[arg] != _c_parser_defaults[arg]: | ||
parser_default = _c_parser_defaults[arg] | ||
if result.get(arg, parser_default) != parser_default: | ||
warnings.warn("The '{arg}' argument has been deprecated " | ||
"and will be removed in a future version" | ||
.format(arg=arg), FutureWarning, stacklevel=2) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't we leave out the actual explanation? As this is not only deprecated, but also does not work (IIUC), so it does not serve much purpose IMO (apart from explaining what feature exactly has never worked, and will never work ..)
BTW, @gfyoung, for the rest strong +1 on your cleaning up of the keywords!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jorisvandenbossche : Will do. Thanks, for the +1 - I use this function a great deal in my own code, so I'm certainly more than happy to improve it given how much it has done for me, even in such a "broken" state. 😄