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

Method for dropping an element of NamedTuple #27574

Closed
Datseris opened this issue Jun 14, 2018 · 17 comments
Closed

Method for dropping an element of NamedTuple #27574

Datseris opened this issue Jun 14, 2018 · 17 comments
Labels
collections Data structures holding multiple items, e.g. sets feature Indicates new feature / enhancement requests

Comments

@Datseris
Copy link

I am trying to do:

d = (solver = 2, b = 3)
f = same tuple as d but without :solver 

The JuliaData/NamedTuples has a delete method, so one can do something like f = delete(d, :solver). It would be nice to have it for Core.NamedTuple as well, if possible.

@Datseris
Copy link
Author

Current workaround:

julia> d = (solver = 2, b = 3, c = 4)
(solver = 2, b = 3, c = 4)

julia> inter = [p for p in pairs(d) if p[1] != :solver]
2-element Array{Pair{Symbol,Int64},1}:
 :b => 3
 :c => 4

julia> f = (; inter...)
(b = 3, c = 4)

(answered on Slack, I think by araslan)

@JeffreySarnoff
Copy link
Contributor

JeffreySarnoff commented Jun 16, 2018

julia> function dropnames(namedtuple::NamedTuple, names::Tuple{Vararg{Symbol}}) 
            keepnames = Base.diff_names(Base._nt_names(namedtuple), names)
           return NamedTuple{keepnames}(namedtuple)
       end
dropnames (generic function with 1 method)

julia> d = (solver = 2, b = 3, c = 4)
(solver = 2, b = 3, c = 4)

julia> dropnames(d, (:solver,))
(b = 3,)

julia> dropnames(d, (:b,))
(solver = 2,)

julia> dropnames(d, (:b,:solver))
NamedTuple()

julia> dropnames(d, (:oops,))
(solver = 2, b = 3)

@Datseris
Copy link
Author

Very nice! Can it also become part of Base or I am being too greedy?

@JeffreySarnoff
Copy link
Contributor

Base has my permission.

@chethega
Copy link
Contributor

Is the inference failure OK (everything becomes Any)?

I would imagine that most use-cases could get away with @generated and val-type symbols (the symbol to drop is a source-code literal). On the other hand, I'd imagine that most uses are not performance critical.

@JeffBezanson
Copy link
Member

There are some utilities for implementing this in base/namedtuple.jl. If diff_names is used to remove the requested name(s) then @JeffreySarnoff's implementation will be inferable.

@JeffreySarnoff
Copy link
Contributor

dropnames implementation improved ^^

@Datseris
Copy link
Author

Datseris commented Jun 21, 2018

@JeffreySarnoff Will you do a PR for this?

(I really hope that this is in the next beta :P )

@JeffreySarnoff
Copy link
Contributor

JeffreySarnoff commented Jun 21, 2018

I don't know what to do about this:

julia> function dropnames(namedtuple::NamedTuple, names::Tuple{Vararg{Symbol}}) 
            keepnames = Base.diff_names(Base._nt_names(namedtuple), names)
           return NamedTuple{keepnames}(namedtuple)
       end
julia> code_warntype(dropnames, (NamedTuple, Tuple{Vararg{Symbol}}))
Body::Any
1 1%1 = Base.diff_names::typeof(Base.diff_names)                                         │
  │   %2 = Base._nt_names::typeof(Base._nt_names)                                           │
  │   %3 = %2(%%namedtuple)::Any                                                            │
  │   %4 = %1(%3, %%names)::Tuple{Vararg{Symbol,N} where N}2%5 = Core.apply_type(Main.NamedTuple, %4)::Type{NamedTuple{_1,T} where T<:Tuple} where _1
  │   %6 = %5(%%namedtuple)::Any                                                            │
  └──      return %6

@JeffBezanson
Copy link
Member

JeffBezanson commented Jun 21, 2018

That happens because NamedTuple is too abstract (in the cal to code_warntype).

@JeffreySarnoff
Copy link
Contributor

submitted PR #27725

@brenhinkeller
Copy link
Contributor

Looks like the PR that implemented this got approved after some debate about naming, but then never merged

@JeffreySarnoff
Copy link
Contributor

+1 reopening and utilizing that PR
if more edits are needed, I will do them

@3f6a
Copy link

3f6a commented Aug 23, 2023

So in the end it seems the decision was not to merge #27725 (we should use NamedTupleTools.delete instead).

If that's the consensus, this issue should be closed. Otherwise, the PR should be reopened (I'd vote for this one!).

@brenhinkeller
Copy link
Contributor

Adding triage label, see #27725 (comment)

@brenhinkeller brenhinkeller added the triage This should be discussed on a triage call label Aug 23, 2023
@LilithHafner
Copy link
Member

Triage discussed this (summary: yes) #27725 (comment)

@LilithHafner LilithHafner removed the triage This should be discussed on a triage call label Nov 9, 2023
@nsajko nsajko added the collections Data structures holding multiple items, e.g. sets label Jul 27, 2024
@JeffBezanson
Copy link
Member

closed by #55270

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
collections Data structures holding multiple items, e.g. sets feature Indicates new feature / enhancement requests
Projects
None yet
Development

No branches or pull requests

8 participants