How is this different from the Compatibility module? Christoph
On Monday, 2 November 2015 20:44:38 UTC, David Anthoff wrote: > > Yes, I like that kind of idea. How about specifically: > > > > - If a package does nothing, every use of `[]` for slicing throws a > deprecation warning on julia 0.5 > > - If you use `using OldArrays` the deprecation goes away, and you get the > julia 0.4 behavior (maybe this options is actually not even needed, or > maybe it should even not exist, not sure) > > - If you use `using NewArrays` you get the new slicing behavior on julia > 0.5 > > > > And then in julia 0.6 `[]` just gives the new behavior by default, i.e. > the `using NewArrays` is no longer needed. In julia 0.6 `using NewArrays` > could actually show a deprecation warning that this using statement is no > longer needed. > > > > *From:* [email protected] <javascript:> [mailto: > [email protected] <javascript:>] *On Behalf Of *Cedric St-Jean > *Sent:* Monday, November 2, 2015 12:00 PM > *To:* julia-users <[email protected] <javascript:>> > *Subject:* Re: [julia-users] Re: Re: are array slices views in 0.4? > > > > Python's > > from __future__ import division > > > was a reasonable way of transitioning. I would use it for slicing if it > was available already. > > On Monday, November 2, 2015 at 2:46:04 PM UTC-5, David Anthoff wrote: > > The `using OldArrays` approach would essentially require an opt-in from > everyone before julia 0.5 is released, i.e. an opt-in action from all > package devs, right? The danger there seems that I update to julia 0.5, but > now I have no clue whether all the packages I rely on have either a) made > sure that they are compatible with the new array handling or b) have added > the `using OldArrays` approach so that they can delay dealing with the > issue. The nice thing with the current deprecation handling is that as a > user of a package that has failed to deal with these things, I get alerted > to issues automatically and know that something might need my attention. > But a `using OldArrays` approach doesn’t seem to do that, in the end it > still just means that the semantics of `[]` are changed without the typical > deprecation sequence of using multiple versions for such a change. > > > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Stefan Karpinski > *Sent:* Tuesday, October 27, 2015 7:43 AM > *To:* Julia Users <[email protected]> > *Subject:* Re: [julia-users] Re: Re: are array slices views in 0.4? > > > > Yes, I'm concerned about this as well. I'm sure we'll come up with > something. Maybe allow using the old behavior during a transitional period > with something like `using OldArrays` and then when you've gotten the > chance to double check your code, you can delete that line and move to the > new behavior. We'll have to see. > > > > On Mon, Oct 26, 2015 at 10:20 PM, David Anthoff <[email protected]> > wrote: > > Are there plans to throw deprecation warnings in julia 0.5 whenever one > slices an array with [], and then reuse the [] syntax to return views in > julia 0.6? That would be approach that is consistent with previous changes > of functionality, right? > > > > I’m very much in favor of the new design, but I’m very worried about the > transition. There seems an enormous potential for subtle bugs to go > undetected for a long time… the tuple change was nicely phased in, as were > any other breaking changes since I’ve used julia (since 0.2), i.e. I always > had the impression that as long as I just fixed all depreciation warnings > when a new version came out, I would be good. But my understanding right > now for the array change is that the behavior of slicing with [] will > change drastically, with essentially no indicator where in my code I might > run into trouble, right? > > > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Stefan Karpinski > *Sent:* Monday, October 26, 2015 12:05 PM > *To:* Julia Users <[email protected]> > *Subject:* Re: [julia-users] Re: Re: are array slices views in 0.4? > > > > On Mon, Oct 26, 2015 at 2:17 PM, Christoph Ortner <[email protected]> > wrote: > > Fabian - Many thanks for your comments. This was very helpful. > > > > (c) if I want to write code now that shouldn't break with 0.5, what should > I do? > > > I think when you need a copy, just surround your getindex with a copy > function. (e.g. copy(x[:,10]) instead of x[:,10]). > > > > But this would lead me to make two copies. I was more interested in seeing > whether there is a guideline on how to write code now so it doesn't have to > be rewritten for 0.5. > > > > There will be a solution in the Compat package once this change is made. > It will probably consist of having a replacement for getindex that creates > a slice rather than a copy so that calling copy won't result in two copies. > I.e. it will backport the 0.5 behavior to earlier versions of Julia. > > > > Regarding this change I am also more on the sceptical side. I would very > much prefer a copy-on-write like solution like Matlab and R provide, but I > don't know if and how this would be possible to implement, so I don't raise > my voice here. > To me the main benefit of this change is that it drove the main developers > to make array views much more performant and first class members of julia. > As Tim Holy mentioned, the actual change seems to be be very small, but it > needed and still needs a lot of work to make it possible. > > > > My own scepticism comes from the idea that using immutable objects > throughout prevents bugs and one should only use mutable objects sparingly > (primarily for performance - but I thought it shouldn't be the default) > > > > Copy-on-write is complex and leads to brittle performance properties that > cannot be reasoned about locally. The semantics of R and Matlab also > notoriously make it impossible to write efficient mutating functions – > people generally end up writing C extensions to do that. > > > > It remains to be seen how this pans out, but keep in mind that C, C++, > Java, Fortran, Julia, Python, Ruby, etc. all use mutable non-copy-on-write > arrays everywhere and the world has not ended. Slices are a bit different, > but NumPy, for example, creates views for slices and that works well in the > SciPy ecosystem. > > > > Philosophically, I think that returning views from operations is > problematic when the object being viewed is conceptually a single value – > strings being a good example that have gone different ways in different > languages. In C everyone thinks of strings as arrays of characters and it > works pretty well since everyone has that in mind. In higher level > languages, people stop thinking of strings this way, which means that > making strings mutable or returning slices of them as views becomes > problematic because it's at odds with how we think of strings. Arrays are > the prototypical example of a container-like thing, so I don't think that > this will be that confusing. If you "own" the array, then it's ok to make a > slice and potentially mutate it – if you don't, then it's not ok. We could > potentially add tooling to help enforce this since we know by the f! naming > convention which functions should and shouldn't mutate their arguments. > > > >
