-
-
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
things we should deprecate, 0.6 edition #19598
Comments
|
Should probably go into StatsModels now. |
Regarding formulas, see JuliaStats/StatsModels.jl#3. |
Alongside With devectorization complete, deprecation of Edit: Also |
I'd also propose depreaction of Edit: done in #19616 – @StefanKarpinski |
For strings, the decision was to define a |
If Jeff's recent String experiment pans out, we'll do that; otherwise we rename the |
|
I think we said that Jeff's recent String experiment is expected to merge in the next few months, otherwise we don't spend any other effort on changing the representation. Probably by 1.0, we will need to have the infrastructure in place to handle Arrays more efficiently via an underlying Buffer type. At that time, we can delete the special case code for String and go back to having a |
Another candidate: |
|
I agree, but these need to wait one release so that we can suggest the alternate spelling without the m. |
The manual has claimed the |
What was wrong with |
It's not a proper type constructor;
Jeff added the text in this commit: 23a6995 |
Ok, as far as I can tell the remaining items to deprecate are: [List moved to top comment] Everything else is either already deprecated or has a fresh PR pending. |
I can definitely deprecate it. I'm not sure I'll be able to resolve all the deprecations in a timely manner, though. Right now it's blocked on #18457. Once that is merged I can push a deprecation branch and we can crowd-source the deprecation fixes. |
This is what @tkelman suggested for that:
That would be the least immediately-breaking course of action, I would think. Once we do stop parsing |
Also:
currently gets rewritten to
which is bad, because the definition looks like it defines
These require #18457. |
There are also some changes to LibGit2 we should make before 1.0 (#19839), but I'm not sure if I'll have time to get to them before then. |
I'd add
|
@nalimilan ^? |
Can I have a link to a PR for the DataFrames |
I've reorganized this issue so that all the todos are in the top comment. A few comments:
If the answer to any of the above is "no", that's ok, just want to update the list so we know what we're still waiting on. |
@ararslan is the one to ask regarding the |
Now that the StatsModels change has happened (thanks, @ararslan!), I don't think the other two changes need to happen in order since they're about tagging new versions and getting the dependencies right. So the next action item there seems to be a PR to change |
Yes, I agree that the changes for |
I actually started on a patch for |
See #20268. |
Is it possible to deprecate using |
Good call, @mbauman – need to do that now in order to use it for discarding values in 1.0. |
Also
|
A few FYIs from me: Special functions: I've been working on moving special functions out of Base. From a package standpoint it's nearly there, but from a modification to Base standpoint there's still a fair bit of work to be done. In particular, to remove the dependency on openspecfun, we'll need to reimplement FFTW: As another data point, I've also been working on moving FFTW into a package. That too is going well, though there is still quite a bit of work to be done in moving from makefiles to BinDeps. Similarly unlikely to make it into 0.6. |
As a temporary solution, could we just copy-pasta the one function you need from openspecfun into libjulia for now, with the longer term plan of reimplementing it in pure Julia? |
I'm cool with that. |
How about moving |
Hm, |
I think SharedArrays are pretty limited and difficult to use. They are not used anywhere in Base itself and SharedArrays is very self-contained. Of course sparse should be moved too, but I have a sense it will be more difficult. It has binary dependencies for example. |
Yeah, makes sense. Perhaps JuliaParallel could adopt a SharedArrays.jl package. @andreasnoack? |
Special functions are on their way out! See #20427 |
Apropos of what? |
I propose closing this. We can still entertain deprecation PRs as they are posted, but I think we're done actively seeking deprecations for 0.6. |
Sure, I think this has served its purpose now. |
I'd like to collect a list of things that should be deprecated before 0.6 is released, even if we don't implement the corresponding feature until 1.0. Some examples I can think of:
Strings:
"hello".data
access – we need to change the representation of strings to make them more efficient, which is almost certainly not going to allow accessing their underlying bytes like this. So we need to deprecate this and provide an alternative API for this sort of thing. fasterString
allocation #19449.Backtick syntax: deprecate using shell-special characters inside of backtick command syntax. At this point we can write most shell constructs in Julia, but it's gotten a bit more verbose and inconvenient than I'd like. So, in 1.0 I'd like to make, e.g.
`echo hello & echo world | sort >> file.txt`
construct a pipeline that runs twoecho
commands in parallel and connects them to the stdin of asort
command and then connects the output ofsort
to the filefile.txt
opened in append mode. deprecate unescaped shell special chars in commands #19786the elementwise meaning of
|
and&
given we're about to have.|
and.&
Deprecate manually vectorized methods in favor of dot syntax, monolithic edition #19791depreaction of
sumabs
,sumabs2
,maxabs
andminabs
which are not necessary with fast function arguments. Deprecate sumabs, sumabs2, minabs, maxabs #19616Array(T, dims...)
(RFC: Deprecate Array(T, dims...) #19989)partial linear indexing, done in RFC: Deprecate partial linear indexing #20079
produce
/consume
(issue Deprecate produce-consume #17699)vectorized
isinteger
, et al. (deprecate array-reducing isinteger #19925)vectorized
frexp
(Deprecate frexp{T<:AbstractFloat}(A::Array{T}) in favor of broadcast ? #19817)promote_eltype_op
(Remove broadcast_elwise_op and deprecate promote_eltype_op #19814)deprecate vectorized ifelse in favor of dot syntax (Deprecate vectorized ifelse in favor of dot syntax #19931)
deprecate
_
as a rvalue (Dummy variable _ #9343, deprecate using_
as an rvalue #20328)~
macro syntax the overall plan from things we should deprecate, 0.6 edition #19598 (comment):change the one user of this as a macro – i.e. StatsModels (WIP: Replace infix ~ for formulas with a model macro JuliaStats/StatsModels.jl#9)
update DataFrames to depend on the new version of StatsModels (issue/PR link?)
change parsing of
~
in Base from macro to plain infix operatorOpen for read and write: we need to get rid of
readandwrite
so whatever deprecation we need to make there should be made. This may be harder since we may need to implement the change. Change open(cmd) to return Process instead of Tuple #12807Inner constructor syntax, see things we should deprecate, 0.6 edition #19598 (comment)
Static parameter syntax, see things we should deprecate, 0.6 edition #19598 (comment)
Deprecate reducer form of
@parallel
: RFC: "for-loop" compliant @parallel for.... take 2 #20259, waiting for a reviewProbably in 1.0 rather than 0.6:
Various special functions, pending Special functions to Base #4301/move special functions out of Base? #8536
full
– @Sacha0, how are we on this?The text was updated successfully, but these errors were encountered: