-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
deprecate getproperty(::Pairs, s)
#39448
Conversation
Hmm, all the test failures in base and stdlib are already not a great sign... |
Seems like one code bug ( |
It was used in InteractiveUtils and accumulate as well, but you are right, it looked more intimidating than it actually was. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be somewhat better to fix these bugs in the code, than just keep them working
@nanosoldier |
Your package evaluation job has completed - possible new issues were detected. A full report can be found here. cc @maleadt |
Looks like this is breaking quite a few packages, so I am not sure that is something we can do for 1.x. Some of the 114 failures seem to be caused by the same packages, but there are still quite a few distinct ones affected. |
x-ref: #25750 |
Yeah, I agree that making this a deprecation for now is probably the best strategy. |
base/iterators.jl
Outdated
get(v::Pairs, key, default) = get(getfield(v, :data), key, default) | ||
get(f::Base.Callable, v::Pairs, key) = get(f, getfield(v, :data), key) | ||
if getproperty !== getfield | ||
@deprecate getproperty(x::Pairs, s::Symbol) getfield(x, s) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@deprecate getproperty(x::Pairs, s::Symbol) getfield(x, s) | |
@eval @deprecate getproperty(x::Pairs, s::Symbol) getfield(x, s) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should go in deprecated.jl
d1e659b
to
cd01bc1
Compare
getproperty(::Pairs, s)
I think triage already approved, so this can be merged in the next couple days |
Co-authored-by: Jameson Nash <[email protected]>
Co-authored-by: Jameson Nash <[email protected]>
Co-authored-by: Jameson Nash <[email protected]>
I have a couple of use-cases where I define: nt(; kw...) = kw.data the deprecation message only mentions |
Either |
|
||
# the plan is to eventually overload getproperty to access entries of the dict | ||
@noinline function getproperty(x::Pairs, s::Symbol) | ||
depwarn("use values(kwargs) and keys(kwargs) instead of kwargs.data and kwargs.itr", :getproperty, force=true) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why the force=true
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need a depwarn version system that allows better granularity, but generally force=false means a v2 (breaking) deprecation while force=true means a user bug. This PR adds a warning for a user bug.
Personally, I think with a forced deprecation warning this is a very annoying change in relation to the benefit it provides. |
Yes, I think I tend to agree. @vtjnash, are you ok with removing the |
* Fix deprecated .data access on ; kw..., see JuliaLang/julia#39448, fixes #154. * Set version to 1.8.2.
Co-authored-by: Jameson Nash <[email protected]>
Warning: use values(kwargs) and keys(kwargs) instead of kwargs.data and kwargs.itr Comes from JuliaLang/julia#39448
This fixes deprecation of kwargs.data in Julia 1.7 (see JuliaLang/julia#39448)
Fixes the deprecation introduced in JuliaLang/julia#39448 (Julia v1.7+)
Last triage there was some discussion about overloading
getproperty
forPairs{<:NamedTuple}
(and perhaps even forAbstractDict{Symbol}
). This would break code that accesses internal fields viagetproperty
, so it would be good to know how much of an impact this would have with a PkgEval run.