Was just playing around and had a panic.

ls | items {|k, v| print $'($k) ($v)' } 
thread 'main' panicked at 'PipelineData::ExternalStream had no span', crates\nu-command\src\filters\items.rs:122:26
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `C:\CarTar\debug\nu.exe` (exit code: 101)

Good catch @fdncred, is there a reason why ls doesn't provide a span ?
Fixed with Span::unknown() when span is not found :)

I have tried to implement items in nu directly:

> def items [f] { transpose | rename a b | each {|key| do $f $key.a $key.b } } 

and then:

 > {new: york, san: francisco} | items {|key value| echo $'($key)-($value)' }
 ╭───┬───────────────╮
│ 0 │ new-york      │
│ 1 │ san-francisco │
╰───┴───────────────╯

I have tried the example of @fdncred, and it gives an output which is probably not the expected one:

 ls | items {|k, v| print $'($k) ($v)' }                                                                                                                                                                                                                                                      03/27/2023 05:37:13 pm
name #*message*-20221028-162839#
type file
size 130 B
modified Sat, 29 Oct 2022 10:40:36 +0200 (4 months ago)

What is the expected result when items is applied on a table?

I think it's important to understand what to do with tables since items is really for records (I think). So, if you look at ls it returns a table or a list of records. ls | columns = keys and ls | values = values. So, ls | items should get those same keys and values, shouldn't it?

BTW - I get this now

ls | items {|k, v| print $'($k) ($v)' } 
Error: nu::shell::only_supports_this_input_type

  × Input type not supported.
   ╭─[source:1:1]
 1 │ nu
   · ▲
   · ╰── input type: raw data
   ╰────
   ╭─[entry #1:1:1]
 1 │ ls | items {|k, v| print $'($k) ($v)' }
   ·      ──┬──
   ·        ╰── only record input data is supported
   ╰────

Another test

ls | each {|r| $r | items {|k, v| print $'key:[($k)] value:[($v)]'}}
key:[name] value:[.cargo]
key:[type] value:[dir]
key:[size] value:[0 B]
key:[modified] value:[Fri, 24 Mar 2023 07:15:50 -0500 (3 days ago)]
key:[name] value:[.github]
key:[type] value:[dir]
key:[size] value:[4.1 KB]
key:[modified] value:[Fri, 24 Mar 2023 07:15:50 -0500 (3 days ago)]
key:[name] value:[.gitignore]
key:[type] value:[file]
key:[size] value:[658 B]
key:[modified] value:[Fri, 24 Mar 2023 07:15:50 -0500 (3 days ago)]
key:[name] value:[.typos.toml]
key:[type] value:[file]
key:[size] value:[254 B]
key:[modified] value:[Fri, 24 Mar 2023 07:15:50 -0500 (3 days ago)]
key:[name] value:[CODE_OF_CONDUCT.md]
key:[type] value:[file]
key:[size] value:[3.5 KB]
key:[modified] value:[Fri, 24 Mar 2023 07:15:50 -0500 (3 days ago)]
key:[name] value:[CONTRIBUTING.md]
key:[type] value:[file]
key:[size] value:[9.8 KB]
key:[modified] value:[Fri, 24 Mar 2023 07:15:50 -0500 (3 days ago)]
key:[name] value:[Cargo.lock]
key:[type] value:[file]
key:[size] value:[151.9 KB]
key:[modified] value:[Mon, 27 Mar 2023 07:18:55 -0500 (3 hours ago)]
key:[name] value:[Cargo.toml]
key:[type] value:[file]
key:[size] value:[5.2 KB]
key:[modified] value:[Mon, 27 Mar 2023 07:18:55 -0500 (3 hours ago)]
key:[name] value:[Cross.toml]
key:[type] value:[file]
key:[size] value:[371 B]
key:[modified] value:[Fri, 24 Mar 2023 07:15:50 -0500 (3 days ago)]
key:[name] value:[LICENSE]
key:[type] value:[file]
key:[size] value:[1.1 KB]
key:[modified] value:[Fri, 24 Mar 2023 07:15:50 -0500 (3 days ago)]
.. truncated

╭────┬────────────────╮
│  0 │ [list 4 items] │
│  1 │ [list 4 items] │
│  2 │ [list 4 items] │
│  3 │ [list 4 items] │
│  4 │ [list 4 items] │
│  5 │ [list 4 items] │
│  6 │ [list 4 items] │
│  7 │ [list 4 items] │
│  8 │ [list 4 items] │
│  9 │ [list 4 items] │
╰────┴────────────────╯
... truncated

The nushell table at the end doesn't look right to me.

Just added support for table type :)

For your example it actually looks good to me @fdncred

You are doing an each on a ls output, hence getting a list of 9 items (your 9 files), each file record was sent into the items command returning nothing (only printing stuff on stdout), so the end result is a list of 9 lists containing each 4 empty elements (4 columns of file record).

If you expand the table you will get

If you return a static value for example, you'll get

What does the python equivalent return? IIRC, this items command came up to kind of mimic that. We may want to make it look like that (if it doesn't already) but more nushell-y.

The Python equivalent looks like :

for key, value in mydict.items():
    print(key, value)

Under the hood, it is a lazy generator returning a tuple containing (key, value)

If we wanted to keep the same principle, it would be something like

mydict | items | each { |keyval| echo $keyval.0 $keyval.1 }

items would then return a list of tuples containing key, value

I find it less concise and agreable to use but I'm open to feedback

ok. I like the non-tuple version myself. Thanks for letting me know.

While avoiding the intermediate record is also great for performance and gives the nicest each replacement given the current syntax (and to a lesser extent type system) capabilities.

I might caveat that having a command that just performs the iteration into a different structure would have benefits for other commands beyond each for basic iteration. This would compose with the other adapters like reduce / skip while but would require some pattern matching like destructuring in the closure arguments or elsewhere to be really pleasant (conflicts with the current implicitly added index in each!).

Furthermore to be as performant as this implementation some additional heavy lifting would probably be necessary, which would be another trade-off.

@sholderbach the user can still transform the record into the type it wants and pipe it into something like reduce

{a: 1, b: 2} | items { |key, value| {key: $key, value: $value } | reduce  ...

We could even add later

{a: 1, b: 2} | items list
# returns [[a, 1], [b, 2]]

Yeah, I would agree. Let's not make perfect the enemy of the good. I think having the ability to quickly write something to operate over records is more valuable right now than perfect iterator design (in a pythonesque or rustic way).
We could iterate on that as soon as we have some diverse user code (cue the breaking changes :D)

Is it ready to merge then :) ?

Instead of Span::unknown() it's better to use call.head. Unknown span points at a random location (whatever was the first input ever parsed by Nushell). The call head points at the items command call.

Otherwise, I don't mind having items, though I think it could be implemented in the standard library.

@Sygmei I think if you can resolve the points by @sholderbach and @kubouch we can land this.

Yes ! I'll try to take some time today to finish this

@fdncred should be good :)

Thanks. Let's go!