Swift is 3 years old. Most people who use it will be on the latest version Swift 4 within a few months. Apple won’t let developers stay behind.
While it was unrealistic for Python to be that aggressive given its larger community, not forcing the issue created a lot of unnecessary work for the community. A benevolent dictator should have moved developers along faster. Having the language fragmented for this long is extremely unproductive.
I don't think Apple could even get away with this if Swift were more than 3 years old. I suspect the relationship between migration pain and age is exponential.
In part it's age. In part, Apple get away with it because they forewarned developers. Swift explicitly intended a "move fast and break things" approach to syntax, naming etc.
Isn't Swift compiled? I'm not sure it's relevant to the specific problems faced here, unless a library written and compiled in earlier versions of Swift won't be usable in a Swift 4 project.
Ah, I see. I assume you could compile to a C compatible library, but they you would have to deal with marshaling costs where the types mismatch, correct?
I like it, "development tough love", ha. I think looking back it becomes clearer in hindsight that it really did consume a lot of community energy. I'm vaguely sensing maybe some kind of community development bystander effect where fixing and upgrading is someone else's problem has kept the divide around longer than it needed to be.
> They added Python 3 features to Python 2 over the years to encourage adoption of Python 3 as the standard. It worked.
Did it really? My impression was the opposite: the fact that so much of Python 3 became available in Python 2 made people feel like there was no point in moving to Python 3.
It worked both ways. Some new features were ported back, some could be ported, but explicitly weren't to encourage migration. On the other side, things like the "u" prefix got re-added to python 3 for compatibility.
They should have created an annotation or something saying "this file uses the python3 dialect", made python3 run all python2 code unmodified (the only way to not require both being on $PATH), and halted python2 releases except critical security bugs.
Aren't there more 2.7 users than 3.x users? I am certain this is true in the scientific community. But I also thought it was true for the general. So telling the majority of your user base "to go fuck themselves" is, generally, not considered a good idea.
GP comment seems like a troll. There is no formula as simple as "always use 3 and don't bother with 2". Not all python2 modules have been ported to python3 and python2 modules are unlikely to be future-supported as long as python3.
Because python3 and python2 are incompatible dialects, you have to say which one you want, and there's no reliable way to use just "python" and no useful reason to have it on $PATH. Any code needs to declare all its dependencies, including either python3 or python2. If I didn't want any specific dependencies, I'd be targeting POSIX and writing in Bourne shell.
If you mean OS distros then this is not a concern. Unless your python needs are very small then you shouldnt use the OS distro for your python apps you should be running them in independent virtual environment with independent versions and packages
Django's next version will be the first that doesn't support Python 2 anymore (because that Django version will be supported longer than Python 2), I hope that that will start the mass updating at my employer's.