Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Proposal: Dict constructors from tuples #4871

Closed
kmsquire opened this Issue · 9 comments

3 participants

Kevin Squire Stefan Karpinski Jeff Bezanson
Kevin Squire
Collaborator

Just putting out feelers: I'd like to propose:

  • removing constructing Dicts from tuples as is currently done

    Dict{K,V}(ks::(K...), vs::(V...)) = Dict{K ,V }(ks, vs)
    Dict{K }(ks::(K...), vs::Tuple ) = Dict{K ,Any}(ks, vs)
    Dict{V }(ks::Tuple , vs::(V...)) = Dict{Any,V }(ks, vs)
    

    (from https://github.com/JuliaLang/julia/blob/master/base/dict.jl#L302)

  • add a dict constructor from a list of tuple pairs (as the inverse of collect on a Dict)

Item 1 seems like a vestige from before we had literal dict construction--is this used anywhere?

Item 2 seems like an oversight.

Kevin Squire
Collaborator

Of course, the easiest way to implement the second constructor would be

Dict{K,V}(kv::Array{(K,V)}) = Dict{K,V}(zip(kv...)...)
Kevin Squire kmsquire closed this
Stefan Karpinski

I'm curious why you closed this? I do think that the collection constructors could use some review for consistency and completeness – Dicts, Sets, Arrays (which are already quite good).

Kevin Squire
Collaborator

Sorry, should have explained better. After making the comment above, I simply created a pull request for the new Dict constructor here: #4872.

Since it uses the other constructors, there didn't seem much point in asking to remove them, and the constructor itself is trivial.

Jeff Bezanson

Dict literals work by calling the Dict(ks,vs) constructors :)

Kevin Squire
Collaborator

How about changing the Dict constructor as you suggested in #4872, and making that the target of Dict literals?

Kevin Squire
Collaborator

(Reopening because of this discussion...)

Kevin Squire kmsquire reopened this
Jeff Bezanson

That would be ok, but the current implementation was picked for efficiency. Of course I could use a hidden dict_literal() for this if we want to keep Dict simpler.

Kevin Squire
Collaborator

I guess my main motivation in wanting to simplify the Dict constructors is to work around #4859, so that

Dict{A,B}(::Type{A},::Type{B})

can exist. Right now, it conflicts with the Dict tuple constructors. If #4859 were addressed, this wouldn't be as necessary.

The above construction would be useful because:
1) This (or #4859) would make other Dict types with more type parameters (OrderedDicts, DefaultDicts) less annoying, since they could have a similar set of constructors, and reasonable type defaults could be provided
2) It's more consistent with Array constructors

Kevin Squire
Collaborator

I wonder how much slower would this be:

Dict(ks, vs) = Dict{eltype(ks), eltype(vs)}(ks,vs)

This would subsume the current interfaces, and still allow

Dict{A,B}(::Type{A},::Type{B})

to exist.

Jeff Bezanson JeffBezanson added this to the 0.3 milestone
Jeff Bezanson JeffBezanson closed this issue from a commit
Jeff Bezanson JeffBezanson fix #4996, fix #4871
change Set, IntSet, and PriorityQueue constructors to accept a single iterable

add an ObjectIdDict constructor accepting an iterable

now you can do this:

```
julia> pairs = [(1,2), (3,4)];

julia> ObjectIdDict(pairs)
{1=>2,3=>4}

julia> Dict(pairs)
[3=>4,1=>2]

julia> Collections.PriorityQueue(pairs)
[3=>4,1=>2]

julia> Set(pairs)
Set{(Int64,Int64)}([(1,2),(3,4)])
```
97364e5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.