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

change set constructor to accept iterables? #4996

Closed
JeffBezanson opened this issue Dec 1, 2013 · 4 comments · Fixed by #5897
Closed

change set constructor to accept iterables? #4996

JeffBezanson opened this issue Dec 1, 2013 · 4 comments · Fixed by #5897
Labels
breaking This change will break code needs decision A decision on this change is needed
Milestone

Comments

@JeffBezanson
Copy link
Member

#4871 suggests constructing dicts from a single iterable argument generating tuples. We should consider doing the same for sets.

While the syntax Set(1,2,3) is nice, it turns ugly when you need to convert a collection to a set, which requires Set(c...). We should avoid expanding an entire collection into an argument list just to pass its elements to a function that wants a collection anyway.

This also fits the planned construct/coerce/convert scheme, since coerce(Set, array) is more natural than coerce(Set, 1, 2, 3, ...).

@StefanKarpinski
Copy link
Member

Writing Set[1,2,3] would be an alternative syntax. It's a slight clash with the Int[1,2,3] syntax but I believe DataArrays may already be doing something along these lines. Perhaps we should formalize the approach as a way of constructing a collection from its elements, where for non-collection types it indicates an Array element type. We probably need a Collection abstract type in Base at this point.

On Dec 1, 2013, at 2:42 AM, Jeff Bezanson notifications@github.com wrote:

#4871 suggests constructing dicts from a single iterable argument generating tuples. We should consider doing the same for sets.

While the syntax Set(1,2,3) is nice, it turns ugly when you need to convert a collection to a set, which requires Set(c...). We should avoid expanding an entire collection into an argument list just to pass its elements to a function that wants a collection anyway.

This also fits the planned construct/coerce/convert scheme, since coerce(Set, array) is more natural than coerce(Set, 1, 2, 3, ...).


Reply to this email directly or view it on GitHub.

@toivoh
Copy link
Contributor

toivoh commented Dec 1, 2013

It holds a certain appeal, but how would I create a vector of sets? I'm worried that such a change would break generic code along the lines of

function f{T}(::Type{T}, x, y)
    args = T[x, y]
    ...
end

@johnmyleswhite
Copy link
Member

We’re removing the DataVector[1, 2, 3] constructor from DataArrays.

— John

On Dec 1, 2013, at 11:56 AM, Stefan Karpinski notifications@github.com wrote:

Writing Set[1,2,3] would be an alternative syntax. It's a slight clash with the Int[1,2,3] syntax but I believe DataArrays may already be doing something along these lines. Perhaps we should formalize the approach as a way of constructing a collection from its elements, where for non-collection types it indicates an Array element type. We probably need a Collection abstract type in Base at this point.

On Dec 1, 2013, at 2:42 AM, Jeff Bezanson notifications@github.com wrote:

#4871 suggests constructing dicts from a single iterable argument generating tuples. We should consider doing the same for sets.

While the syntax Set(1,2,3) is nice, it turns ugly when you need to convert a collection to a set, which requires Set(c...). We should avoid expanding an entire collection into an argument list just to pass its elements to a function that wants a collection anyway.

This also fits the planned construct/coerce/convert scheme, since coerce(Set, array) is more natural than coerce(Set, 1, 2, 3, ...).


Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub.

@kmsquire
Copy link
Member

kmsquire commented Dec 6, 2013

If generators (#4470) were implemented, xs... notation could be turned into a generator, which if efficient could be used here (and likely other places).

@JeffBezanson JeffBezanson added this to the 0.3 milestone Feb 18, 2014
JeffBezanson added a commit that referenced this issue Feb 22, 2014
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)])
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking This change will break code needs decision A decision on this change is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants