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 sort for NTuple and other iterables #811

Closed
wants to merge 1 commit into from

Conversation

martinholters
Copy link
Member

As this functionality was removed from Julia in JuliaLang/julia#52010.

CC @ericphanson

@martinholters
Copy link
Member Author

martinholters commented Nov 27, 2023

This is on top of #810 to see whether tests now pass on nightly. EDIT: Rebased after merging #810.

Copy link

codecov bot commented Nov 27, 2023

Codecov Report

Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (db2077e) 92.83% compared to head (e900807) 93.23%.

Files Patch % Lines
src/deprecated.jl 96.15% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #811      +/-   ##
==========================================
+ Coverage   92.83%   93.23%   +0.39%     
==========================================
  Files           2        3       +1     
  Lines         335      340       +5     
==========================================
+ Hits          311      317       +6     
+ Misses         24       23       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

# https://github.com/JuliaLang/julia/pull/46104
# reverted in https://github.com/JuliaLang/julia/pull/52010
if VERSION < v"1.10.0-DEV.1404" ||
(VERSION >= v"1.10-rc2" && VERSION < v"1.11.0-") ||
Copy link
Member Author

Choose a reason for hiding this comment

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

This assumes that JuliaLang/julia#52010 will actually be in v1.10-rc2.

Comment on lines +25 to +35
function Base.sort(v; kws...)
Base.depwarn("sorting arbitrary iterables is deprecated", :sort)
if v isa AbstractString
throw(ArgumentError("sort(::AbstractString) is not supported"))
end
if v isa NTuple
return _sort(v; kws...)
end
if v isa Tuple
throw(ArgumentError("sort(::Tuple) is only supported for NTuples"))
end
Copy link
Member Author

Choose a reason for hiding this comment

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

I've changed the dispatch to only add this single method to Base.sort. If part of this functionality is re-added toBase in the future, it will likely be for more specific argument types and we then won't overwrite these new methods. Adding this method Base for any future Julia versions still makes me a bit uncomfortable.

@@ -696,8 +696,6 @@ end
@testset "sort(iterable)" begin
function tuple_sort_test(x)
@test issorted(sort(x))
length(x) > 9 && return # length > 9 uses a vector fallback
@test 0 == @allocated sort(x)
Copy link
Member Author

@martinholters martinholters Nov 27, 2023

Choose a reason for hiding this comment

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

These now allocate due to depwarn.

@martinholters
Copy link
Member Author

The sort tests still pass (except for the @allocated ones), but of course are quite noise with many depwarns now. Should we remove them?

@martinholters martinholters marked this pull request as ready for review November 28, 2023 07:06
@KristofferC
Copy link
Member

KristofferC commented Nov 28, 2023

No, this has to be reverted. We cannot have this level of type piracy in Compat just because it existed on Julia master for a while.

I mean, Compat should not even overload things in Base. You are supposed to have to call Compat.sort if you want to opt in to the "future" behavior of sort.

@martinholters
Copy link
Member Author

No, this has to be reverted. We cannot have this level of type piracy in Compat just because it existed on Julia master for a while.

Yeah, that is super unfortunate, but if we just revert this, we have to do a new major version if we take SemVer seriously (which I like to do). And new major versions of Compat are not welcome by everyone, ref. #767 (comment). A middle ground might be to keep this (deprecated) in Compat but only for Julia < v1.10. That would mean that for sort on general iterables, you'd need Julia < 1.10. Not sure that's much better, but at least, Compat doesn't pollute Base forever then.

I mean, Compat should not even overload things in Base. You are supposed to have to call Compat.sort if you want to opt in to the "future" behavior of sort.

Hm, we've traditionally added methods to functions in Base whenever possible, reasoning that we're only doing it for past Julia versions where we know it's safe. And it's convenient from a user perspective. But I agree that always requiring the Compat. prefix would be much safer. We might want to adopt that in the future. But it doesn't help us with the mess we're in here now.

Comment on lines +21 to +23
if VERSION < v"1.10.0-DEV.1404" ||
(VERSION >= v"1.10-rc2" && VERSION < v"1.11.0-") ||
VERSION >= v"1.11.0-DEV.924"
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
if VERSION < v"1.10.0-DEV.1404" ||
(VERSION >= v"1.10-rc2" && VERSION < v"1.11.0-") ||
VERSION >= v"1.11.0-DEV.924"
if VERSION < v"1.10.0-DEV.1404"

To stop adding methods to Base.sort in future Julia versions while keeping sort working on general iterables on Julia < 1.10 with Compat (where people might already be using it).

Ref. #811 (comment)

@KristofferC
Copy link
Member

KristofferC commented Nov 29, 2023

Can we at least run PkgEval on this change and see if it breaks something in practice and if not we just remove it? Having this deprecated (but still there) in all of < 1.10 is awful. It shouldn't even be there in the first place since this is a feature that was introduced in 1.10 and should not automatically be available on pre-1.10. We don't backport features for a reason.

The type of development where things that are tested on Julia master quickly get put into Compat in a type piracy way and then "cannot be removed due to semver" is completely unworkable. This package is depended on by a lot of other packages and any type piracy in it is very bad.

FWIW, I also think this change broke a package (https://s3.amazonaws.com/julialang-reports/nanosoldier/pkgeval/by_hash/46617e5_vs_0ba6ec2/ITensorVisualizationBase.primary.log) where, ironically, their own type piracy (https://github.com/ITensor/NDTensors.jl/blob/19c079c554b546c57b3f5bd72db15c39112ff5d0/src/tupletools.jl#L162) stopped working.

So at least we have some evidence that the added type piracy here broke a package so based on semver (which we take seriously) it should be reverted.

@ericphanson
Copy link

In the past, “not matching Julia” has been called a bugfix btw: #745

@martinholters
Copy link
Member Author

Yeah, these are good arguments for reverting.

Can we at least run PkgEval on this change

Can nanosoldier to this for us or would someone need to run it on their own box?

Meanwhile, searching for Compat = "4.9" only found NDTensors, so that's a likely candidate for being broken -- again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants