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

deprecate getproperty(::Pairs, s) #39448

Merged
merged 3 commits into from
Apr 27, 2021
Merged

deprecate getproperty(::Pairs, s) #39448

merged 3 commits into from
Apr 27, 2021

Conversation

simeonschaub
Copy link
Member

Last triage there was some discussion about overloading getproperty for Pairs{<:NamedTuple} (and perhaps even for AbstractDict{Symbol}). This would break code that accesses internal fields via getproperty, so it would be good to know how much of an impact this would have with a PkgEval run.

@simeonschaub simeonschaub added DO NOT MERGE Do not merge this PR! needs pkgeval Tests for all registered packages should be run with this change labels Jan 29, 2021
@simeonschaub
Copy link
Member Author

Hmm, all the test failures in base and stdlib are already not a great sign...

@vtjnash
Copy link
Member

vtjnash commented Jan 29, 2021

Seems like one code bug (kw.data === NamedTuple() instead of isempty(kw)) that gets run frequently. That code (70d8497) hasn't even made it into a release yet.

@simeonschaub
Copy link
Member Author

It was used in InteractiveUtils and accumulate as well, but you are right, it looked more intimidating than it actually was.

Copy link
Member

@vtjnash vtjnash left a 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

base/reduce.jl Outdated Show resolved Hide resolved
stdlib/InteractiveUtils/src/macros.jl Outdated Show resolved Hide resolved
base/accumulate.jl Outdated Show resolved Hide resolved
base/accumulate.jl Outdated Show resolved Hide resolved
base/accumulate.jl Outdated Show resolved Hide resolved
base/accumulate.jl Outdated Show resolved Hide resolved
base/accumulate.jl Outdated Show resolved Hide resolved
base/accumulate.jl Outdated Show resolved Hide resolved
@simeonschaub
Copy link
Member Author

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

@nanosoldier
Copy link
Collaborator

Your package evaluation job has completed - possible new issues were detected. A full report can be found here. cc @maleadt

@simeonschaub
Copy link
Member Author

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.

@simeonschaub
Copy link
Member Author

x-ref: #25750

base/iterators.jl Outdated Show resolved Hide resolved
@simeonschaub
Copy link
Member Author

Yeah, I agree that making this a deprecation for now is probably the best strategy.

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)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
@deprecate getproperty(x::Pairs, s::Symbol) getfield(x, s)
@eval @deprecate getproperty(x::Pairs, s::Symbol) getfield(x, s)

Copy link
Member

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

@simeonschaub simeonschaub changed the title [DO NOT MERGE] error for getproperty(::Pairs, ...) deprecate getproperty(::Pairs, s) Apr 13, 2021
@simeonschaub simeonschaub added deprecation This change introduces or involves a deprecation and removed DO NOT MERGE Do not merge this PR! needs pkgeval Tests for all registered packages should be run with this change labels Apr 13, 2021
base/deprecated.jl Outdated Show resolved Hide resolved
@vtjnash vtjnash marked this pull request as ready for review April 14, 2021 03:04
@simeonschaub simeonschaub added the triage This should be discussed on a triage call label Apr 15, 2021
@vtjnash
Copy link
Member

vtjnash commented Apr 16, 2021

I think triage already approved, so this can be merged in the next couple days

@simeonschaub simeonschaub added merge me PR is reviewed. Merge when all tests are passing and removed triage This should be discussed on a triage call labels Apr 27, 2021
@simeonschaub simeonschaub merged commit ff001a4 into master Apr 27, 2021
@simeonschaub simeonschaub deleted the sds/getprop_pairs branch April 27, 2021 11:27
@simeonschaub simeonschaub removed the merge me PR is reviewed. Merge when all tests are passing label Apr 28, 2021
ElOceanografo pushed a commit to ElOceanografo/julia that referenced this pull request May 4, 2021
jarlebring pushed a commit to jarlebring/julia that referenced this pull request May 4, 2021
antoine-levitt pushed a commit to antoine-levitt/julia that referenced this pull request May 9, 2021
@quinnj
Copy link
Member

quinnj commented May 11, 2021

I have a couple of use-cases where I define:

nt(; kw...) = kw.data

the deprecation message only mentions keys(kw) or values(kw), so how do we get a NamedTuple from kw? Should I just change them to getfield(kw, :data)?

@simeonschaub
Copy link
Member Author

Either values(kw) or NamedTuple(kw) should work. (I think the latter might only work on more recent versions of Julia.)

fredrikekre added a commit to fredrikekre/JSON3.jl that referenced this pull request May 13, 2021

# 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)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the force=true?

Copy link
Member

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.

@KristofferC
Copy link
Member

Personally, I think with a forced deprecation warning this is a very annoying change in relation to the benefit it provides.

@simeonschaub
Copy link
Member Author

Yes, I think I tend to agree. @vtjnash, are you ok with removing the force=true?

quinnj pushed a commit to quinnj/JSON3.jl that referenced this pull request May 25, 2021
* Fix deprecated .data access on ; kw..., see JuliaLang/julia#39448, fixes #154.

* Set version to 1.8.2.
johanmon pushed a commit to johanmon/julia that referenced this pull request Jul 5, 2021
visr added a commit to visr/AxisKeys.jl that referenced this pull request Jul 26, 2021
    Warning: use values(kwargs) and keys(kwargs) instead of kwargs.data and kwargs.itr

Comes from JuliaLang/julia#39448
stuartthomas25 added a commit to stuartthomas25/TypedTables.jl that referenced this pull request Aug 24, 2022
This fixes deprecation of kwargs.data in Julia 1.7 (see JuliaLang/julia#39448)
quinnj pushed a commit to apache/arrow-julia that referenced this pull request Mar 23, 2023
Fixes the deprecation introduced in JuliaLang/julia#39448 (Julia v1.7+)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deprecation This change introduces or involves a deprecation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants