The Python 3 breaking changes were a big mess for them, because by that time people had built lots of code around Python 2. There seems to be a similar problem happening now with updates to TensorFlow. What areas might lead to similar issues for Julia? What is being done, or can be done, to prevent…

I find what Guido van Rossum said in a talk last year very interesting: What we intentionally didn’t do but what I still regret is that we said there will be no way at run-time to combine Python 2 and Python 3 code in the same process, in the same Python interpreter. […] That sadly made it so that…

Julia has at least two major advantages: macros, and fast FFI. The first provides a lot of room for tooling like Compat.jl (for better or worse). The latter means that there is very little module code using the libjulia C API, except for unavoidable cases like embedding. The fact that Python 3 intro…

[image] ihnorton: Julia has at least two major advantages: macros, and fast FFI I think there’s a third major and even more important advantage which makes Compat (and it’s evil cousin @deprecate) work much better than expected: we have a solution to the expression problem . Because of this on…

I would be surprised if Julia v2.0 is that different from Julia v1.0, at least in syntax and Base. The only major change I can see a huge demand for is the addition of traits, but this could be done without breaking existing code. The other change is “fixing” the global scope issues when code is run…

I think that 2.0 will also be used as an opportunity to make all those tiny changes which are now shelved because they are considered breaking (API consistency issues, changes to semantics of functions, …; the label linked is just a subset of these). Just like it happened before 1.0. There is no po…

Right, I didn’t mean to imply they would not be breaking, just not on the same level as Python 2 → 3. Actually, I’d bet the changes are less extreme than Julia 0.6->0.7…

One thing Julia has in its favor, I think, is that Julia already has a, uh, “culture of source transformation”. It’s already relatively easy to achieve most desired semantic outcomes with macros and the like. I think it already provides a more obvious path for creating robust conversion tools to tra…

[image] ninjaaron: Doesn’t cover everything, but it covers a lot, I would argue that macros can (theoretically) cover anything that parses. However, Julia 2 is likely to include some modifications to the parser itself. Hence, it would be really neat if the Compat package would contain a copy…

Supporting calling older code from newer code makes sense. I don’t think it makes much sense to support calling newer versions from older versions. We want to encourage people to update, not make it easy for them to stay on the same version forever.

I would argue the opposite. If it is easy to call old code from new Julia, but not the other way around, then the path of least resistance for package maintainers will be to stay on Julia 1. Upgrading to Julia 2 would require maintaining two versions of the code, unless all end users have already up…

Avoiding a Julia version of the Python 2/3 mess

Internals & Design

Topic		Replies	Views
[Article] Dear Google Cloud: Your Deprecation Policy is Killing You Internals & Design compatibility	57	4937	December 14, 2020
Thoughts on eventual Julia 2.0 transition Internals & Design upgrades	47	9952	October 15, 2018
Forward compatibility and stability of Julia vs. Packages General Usage	97	4970	August 27, 2023
Package compatibility with language versions General Usage	7	887	July 16, 2020
Julia version change [how much change , programmer should fear] Community	4	1135	December 14, 2020

Avoiding a Julia version of the Python 2/3 mess

Related topics