variable numbers of keyword arguments as dict

[WestleyArgentum]

foo(; args...)

Inside of a function with this signature, args will be an array of tuples containing symbols and values. Cool, but the array will be unordered, so I pretty much have to loop over it trying to match symbols.

I think it would be really cool if args came in as a dictionary. I'm guessing there would be some overhead involved in that, and that's perhaps why it has not been done. But I wonder if the overhead involved in looping over symbols and doing a bunch of string comparisons (I think that's what's happening, could be wrong) might even outweigh the dict creation.

I didn't see an issue, but has this been considered?

[JeffBezanson]

I'd recommend doing some performance experiments. I suspect a dict wouldn't be a win until the number of keyword arguments was pretty large (probably > 20), which doesn't happen very often.

[kmsquire]

One option might be to make a new dictionary type for small dictionaries
like this, which could implement a dictionary interface, but simply be
stored as two lists or a list of tuples.

On Sunday, November 24, 2013, Jeff Bezanson wrote:

I'd recommend doing some performance experiments. I suspect a dict
wouldn't be a win until the number of keyword arguments was pretty large
(probably > 20), which doesn't happen very often.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4916#issuecomment-29172755
.

[WestleyArgentum]

I'll try to do some tests soon. I like @kmsquire's idea, at least then use code isn't cluttered with blocks of if elseif elseif... statements

[remusao]

Don't know if @WestleyArgentum had time to dig into this issue, but I think it would be a good idea to have varargs keyword arguments as a Dict (like in Python for example). From usability point of view I think it would be a win (I find it more natural).

If there is a performance cost, as @kmsquire said, maybe we could try to implement a Dict type efficient for small amount of values inside ?

Edit:
I tried to do some test here
https://gist.github.com/remusao/9344557

I compare access time to Vector{(Symbol, ASCIIString)} and Dict{Symbol, ASCIIString} with various number of elements (1 -> 100). For each test case, I look 100k for every element in the collection.

On my machine:

• i7 860 (2.8 Ghz)

It seems that Array are faster until number of elements reach 14 (I agree that it is a lot of keyword arguments...). And then Dict becomes faster. But while Array is faster for few elements, the difference seems quite reduced. For 100k x (access to each element of the collection), the difference is always x millisecs.

Tell me if I'm wrong about the bench, but from a performance point of view, the advantage of Array over Dict seems negligible.

[stevengj]

Note that the issue of having a specialized Associative type for small dictionaries, perhaps even specialized to dictionaries with Symbol keys, was also raised in #7959.

[ntessore]

I think such a situation could be handled in a uniform way with a function that goes over pairs:

julia> function findbykey(a, key)
           for (k, v) in a
               k == key && return v
           end
           error("not found")
       end
findbykey (generic function with 1 method)

julia> d = { "a" => "A", "b" => "B", "c" => "C" }
Dict{Any,Any} with 3 entries:
  "c" => "C"
  "b" => "B"
  "a" => "A"

julia> findbykey(d, "c")
"C"

julia> d = [ ("a", "A"), ("b", "B"), ("c", "C") ]
3-element Array{(ASCIIString,ASCIIString),1}:
 ("a","A")
 ("b","B")
 ("c","C")

julia> findbykey(d, "c")
"C"

[stevengj]

@ntessore, except that this is a terrible way to look up something in a Dict (though I suppose you could define findbykey(a::Associative, key) = a[key]). You really want to overload get, and that requires a new type.

The point is that there are potentially several places where a specialized SmallDict type could be useful, and if we were to define such a type it would be nice to use it for keywords too.

[ntessore]

Of course it does not make any sense for a Dict, but that was the first container holding pairs I could think of. My point was that it is generally useful to extract something from a set of (key, value) pairs, so maybe there is room for a generic function (that one can then specialise as necessary, e.g. for dictionaries).

[stevengj]

(In Scheme, the findbykey function is called assoc.)

[remusao]

Why not adding a method get to array of pairs?
On Nov 11, 2014 8:40 PM, "Steven G. Johnson" notifications@github.com
wrote:

(In Scheme, the findbykey function is called assoc.)

Reply to this email directly or view it on GitHub
#4916 (comment).

[stevengj]

@remusao, because arrays already have a get method: get(A, i, default) or A[i] look up by index.

[GlenHertz]

I sometimes want to print out the args in the same order so I wouldn't want to have this turned into an unordered dict. I would much rather have a new datatype that was optimized for a list of pairs that was really fast for <5 pairs.

[StefanKarpinski]

Varargs keywords will either be immutable dicts or named tuples, so this will be fixed in 1.0 one way or another.

[micklat]

Whatever you do, please preserve the argument order (so either a tuple or an ordered dictionary would keep me happy).

[ViralBShah]

Would be great to have an update on if this is happening by feature freeze. A PR exists in #21915, but that is not marked 1.0.

[JeffBezanson]

I'll update that PR to use named tuples.

[oscardssmith]

Doesn't that mean that every time you use a function with a different ordering of keyword arguments it will have to create a new specialization of Tupple? Is there any way around this?

[JeffBezanson]

Basically yes, but that won't necessarily be a problem in practice. We'll find out.