Skip to content
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

drop column when given a record always produces an empty record instead of either erroring or deleting a column #6846

Closed
webbedspace opened this issue Oct 21, 2022 · 1 comment
Labels
inconsistent-behavior Behavior between different commands or types inconsistent/unexpected semantics Places where we should define/clarify nushell's semantics type-system Problems or features related to nushell's type system
Milestone

Comments

@webbedspace
Copy link
Contributor

Describe the bug

As I understand it, records are "1-row data structures", which means every key is a column and every value is an element in that column. However, with that understanding, drop column doesn't work with it. It always returns a {record 0 items} instead of either erroring or dropping a column (a key).

How to reproduce

〉open package.json
╭─────────────────┬──────────────────────────────────╮
│ name            │ nushell.github.io                │
│ version         │ 0.0.0                            │
│ description     │ The Nushell website (nushell.sh) │
│ repository      │ github:nushell/nushell.github.io │
│ type            │ module                           │
│ scripts         │ {record 4 fields}                │
│ license         │ MIT                              │
│ devDependencies │ {record 11 fields}               │
│ lint-staged     │ {record 1 field}                 │
│ dependencies    │ {record 3 fields}                │
╰─────────────────┴──────────────────────────────────╯
〉open package.json | drop column 1 | describe
record<>
〉open package.json | drop column 1

〉

Expected behavior

I actually think this would make sense if it errored, because records are technically not ordered structures ("technically" in the sense that most programming languages, including JavaScript, do have a specification-defined algorithm for what happens when you iterate over a record's items) so referring to record columns by number is arguably invalid, and you should use reject instead. However, I can see an argument for permitting it anyway.

Screenshots

No response

Configuration

key value
version 0.70.0
branch
commit_hash 9ef65dc
build_os windows-x86_64
build_target x86_64-pc-windows-msvc
rust_version rustc 1.64.0 (a55dd71d5 2022-09-19)
rust_channel stable-x86_64-pc-windows-msvc
cargo_version cargo 1.64.0 (387270bc7 2022-09-16)
pkg_version 0.70.0
build_time 2022-10-18 18:55:02 +00:00
build_rust_channel release
features database, dataframe, default, trash, which, zip
installed_plugins

Additional context

No response

@sholderbach sholderbach added type-system Problems or features related to nushell's type system inconsistent-behavior Behavior between different commands or types inconsistent/unexpected semantics Places where we should define/clarify nushell's semantics labels Oct 21, 2022
sholderbach pushed a commit that referenced this issue Nov 9, 2023
# Description
This PR refactors `drop columns` and fixes issues #10902 and #6846.
Tables with "holes" are now handled consistently, although still
somewhat awkwardly. That is, the columns in the first row are used to
determine which columns to drop, meaning that the columns displayed all
the way to the right by `table` may not be the columns actually being
dropped. For example, `[{a: 1}, {b: 2}] | drop column` will drop column
`a` instead of `b`. Before, this would give a list of empty records.

# User-Facing Changes
`drop columns` can now take records as input.
@sholderbach
Copy link
Member

Closed by #10903

@hustcer hustcer added this to the v0.87.0 milestone Nov 9, 2023
hardfau1t pushed a commit to hardfau1t/nushell that referenced this issue Dec 14, 2023
# Description
This PR refactors `drop columns` and fixes issues nushell#10902 and nushell#6846.
Tables with "holes" are now handled consistently, although still
somewhat awkwardly. That is, the columns in the first row are used to
determine which columns to drop, meaning that the columns displayed all
the way to the right by `table` may not be the columns actually being
dropped. For example, `[{a: 1}, {b: 2}] | drop column` will drop column
`a` instead of `b`. Before, this would give a list of empty records.

# User-Facing Changes
`drop columns` can now take records as input.
dmatos2012 pushed a commit to dmatos2012/nushell that referenced this issue Feb 20, 2024
# Description
This PR refactors `drop columns` and fixes issues nushell#10902 and nushell#6846.
Tables with "holes" are now handled consistently, although still
somewhat awkwardly. That is, the columns in the first row are used to
determine which columns to drop, meaning that the columns displayed all
the way to the right by `table` may not be the columns actually being
dropped. For example, `[{a: 1}, {b: 2}] | drop column` will drop column
`a` instead of `b`. Before, this would give a list of empty records.

# User-Facing Changes
`drop columns` can now take records as input.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
inconsistent-behavior Behavior between different commands or types inconsistent/unexpected semantics Places where we should define/clarify nushell's semantics type-system Problems or features related to nushell's type system
Projects
None yet
Development

No branches or pull requests

3 participants