Return errors on unexpected inputs to take and first#7123
Return errors on unexpected inputs to take and first#7123rgwood merged 3 commits intonushell:mainfrom
take and first#7123Conversation
Ah, I didn't realize that we treat strings as iterable, but so, yes, I think either strings are iterable and they behave mostly like lists of characters including with |
|
@dandavison I think I come down on the side of "strings are iterable", but I would prefer to leave that for another PR. For this PR I mostly wanted to clean up the obviously wrong behaviour. |
|
Incidentally (not blocking this PR) I see other commands accepting non-iterable input, e.g. |
|
Yeah, webbedspace has a big list: #6941 |
| // if we want more rows that the current chunk size (8192) | ||
| // we must gradually get bigger chunks while testing | ||
| // if it's within the requested rows_desired size |
There was a problem hiding this comment.
For posterity: I think this code was left over from an earlier time and no longer necessary. I tested the new functionality and it is able to get byte ranges larger than 8192 bytes.
Previously,
firstandtakewere very loosey-goosey about the types of data they would accept. If given a type that isn't really iterable, they would often just return the input as-is (sometimes wrapping it in a list):I believe this behaviour was accidental, an artifact of how
takeandfirstwere implemented. I've done a refactoring to maketakeandfirstmore robust when given unexpected input types:This has the nice side effect of fixing #7121. The PR partially addresses #6941.
Future Work
Maybe these commands should handle strings by essentially performing a substring operation? That would be consistent with how they operate on binary values.