161–170 of 733 posts
To clarify: long-term means automotive time scales: I want to be able to run my software in 10 years.
Earlier quoted context omitted.
Not really. :-) ANSI C is very different to the whole pre-ANSI zoo of C-like languages. Most of the code I saw from that age would never compile on modern post-ANSI compilers.
Nonsense. I just compiled a pretty large project from the stone age using a modern day compiler. It required a few lines of change in all to make it compile and it ran the first time it compiled. C has many warts and design errors but they got the portability bit down quite well, the biggest problems you will run into are assumptions by programmers rarely assumptions by the designers of the language. One major thing…
Ok, now do the reverse. ;)
The work involved to upgrade from Python 2 to Python 3 for most things will be more like what you did (fixing a few things here and there), certainly not anywhere near as hard as what I challenged with above.
When people mock me for writing long-term projects in Perl 5 ( https://github.com/jwr/ccheck ), I point them to the Python2/3 change. From an outsider's point of view, this change was not coordinated well and the timeline is too short. To clarify: long-term means automotive time scales: I want to be able to run my software in 10 years.
Python 2's EOL was first announced in 2008.
Earlier quoted context omitted.
Nonsense. I just compiled a pretty large project from the stone age using a modern day compiler. It required a few lines of change in all to make it compile and it ran the first time it compiled. C has many warts and design errors but they got the portability bit down quite well, the biggest problems you will run into are assumptions by programmers rarely assumptions by the designers of the language. One major thing…
That you could easily port an old C code to modern compilers seems doesn't seem to be in contradiction to the statement that old code will not compile as is .
Earlier quoted context omitted.
Based on your timeline, a four year gap from "not yet ready to migrate" to "we won't fix security vulnerabilities" is very short. Python is an open source project I've used and contributed nothing to, so I don't have the right to be a back seat driver. Were it a commercial project and I was a customer, I would be quite upset.
Python 2's EOL was first announced in 2008, it was extended in 2014. That's more than a decade of forewarning that this was coming down the line. A decade of Python2 receiving security fixes. Were I a commercial customer, and had been told to switch to the new version ten years ago, then it's on me if I still have started the migration yet.
> If people find catastrophic security problems in Python 2, or in software written in Python 2, then volunteers will not help you. If you need help with Python 2 software, then volunteers will not help you. Well, isn't it the benefit of FOSS, that volunteers can, and in the case of such a critical piece, so much used as Python 2, in all probability will, step up. Doesn't have to be the same people as the core team i…
Exactly! I am getting tired of FOSS orgs thinking they can speak for their entire extended community. `PSF` should be inserted before every occurance of the word volunteer in that page.
In 2015, there was no way I could have moved to Python 3. There were too many libraries I depended on that hadn't ported yet. In 2019, I feel pretty confident about using Python 3, having used it exclusively for about 18 months now. For my personal use case at least, this timeline worked out well for me. Hopefully it works out for most everyone. I can't imagine they made this decision without at least some data backi…
Mind that there is a feedback loop between data of current usage and an eol announcement.
If they announce an EOL close by this creates pressure to migrate.
Earlier quoted context omitted.
Continuing a fork under the original name would be confusing to everyone and bad manners, aside from infringing the trademark. But nobody is stopping people from organising around a fork called "Omphalos - a Python 2 fork" or whatever
Somebody has done just that already, it’s easily googleable. Nobody really cares though - why would you purposefully tie yourself to an objectively-inferior featureset, full of problems that have already been solved in py3? Because you can’t bear the use of parentheses for print, really?
While I generally share your POV, it doesn’t do justice to the situation to trivialize the upgrade like that. Anyone with C based dependencies will have a rougher time (but not that “rough”) due to ABI changes. The harder userland change is string handling anyway (which isn’t that hard either), not parens on print.
When people mock me for writing long-term projects in Perl 5 ( https://github.com/jwr/ccheck ), I point them to the Python2/3 change. From an outsider's point of view, this change was not coordinated well and the timeline is too short. To clarify: long-term means automotive time scales: I want to be able to run my software in 10 years.
If 12 years is too short, how long timescale do you need? Python 2's EOL was first announced in 2008.
When people mock me for writing long-term projects in Perl 5 ( https://github.com/jwr/ccheck ), I point them to the Python2/3 change. From an outsider's point of view, this change was not coordinated well and the timeline is too short. To clarify: long-term means automotive time scales: I want to be able to run my software in 10 years.
If 12 years is too short, how long timescale do you need? Python 2's EOL was first announced in 2008.