add Type to kwargs internal argument

[vtjnash]

Fixes #39419

[Sacha0]

Out of curiosity, why reorder? (You successfully nerd sniped me 😄.)

[vtjnash]

oops, that wasn't for this PR (I was timing ArgTools, and wondering why it was one of the slower packages to load)

[timholy]

Awesome, thanks so much! While you're at it, maybe change

julia/base/namedtuple.jl

Line 293 in ce5bd1c

k = k::Symbol

to k = Symbol(k)? While I think the typeassert was practically the right thing to do at the time, it's a weird limitation for an exported, generic function like merge and where itr can be anything. (Presumably we should support any keys from which a Symbol can be created, or at least those which can convert to a Symbol.)

If you're at all worried about the possibility of invalidation regressions, you can check the invalidations from PyPlot. I'm sure you've done this before many times, perhaps using more low-level tools, but in case it saves you any time here's a recipe of how I'd do this:

julia> using SnoopCompileCore

julia> invs = @snoopr using PyPlot;

julia> using SnoopCompile

julia> length(uinvalidated(invs))
1220

😱 Something has already regressed! Looks like 8e61551.

So the bar is low for this particular change, get it in before others raise the standards! 🙂

[JeffBezanson]

This seems a bit strange to have as a method; maybe just make it a constant instead?

[JeffBezanson]

This could be merged with the first definition of restkw.

[vtjnash]

computing rkw needs the initial form (to stringify the variable name) before this wrapper is applied

[JeffBezanson]

to k = Symbol(k)?

That would be a dramatic change, since we allow constructing a Symbol from anything by stringification.

[timholy]

Oh, funny I didn't know that. convert(Symbol, k) then?

[JeffBezanson]

Have you come across a use case for it? I'm surprised to see the Invalidation Czar himself propose this :)

[timholy]

Nah. For me Symbols live in their own world; until just now I also hadn't really that there are no objects in Base that convert to Symbol:

julia> methods(convert, (Type{Symbol}, Any))
# 1 method for generic function "convert":
[1] convert(::Type{T}, x::T) where T in Base at essentials.jl:171

All this explains why that change passed tests and hasn't caused other known problems. I was just motivated by the fact that it looks like a generic method, even if nothing takes advantage of that. If nothing else we could document that the keys must be Symbol.

[vtjnash]

@nanosoldier runbenchmarks(ALL, vs=":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @christopher-dG

[timholy]

Thanks again, @vtjnash!