131–140 of 733 posts
One missing question: Q) I like Python 2. Can I take over Python 2 maintenence? A) NO. Try it and we'll sue you.
More like Q) I like Python 2. Can I take over Python 2 maintenence? A) Sure. Just don't pretend to be us; call your fork something other than Python 2
Earlier quoted context omitted.
It's having to write the parenthesis after print. No one wants that and it's been by far the largest complaint the community has about python3.
> No one wants that Why would you write a statement that is so demonstrably false?
Earlier quoted context omitted.
Many systems still run COBOL today The latest official COBOL spec is COBOL 2014 and there are at least two or three competing companies out there that will happily sell you up to date COBOL tools and compilers. So while COBOL may be old, there are still new 'exciting' things happening in the COBOL space.
> there are still new 'exciting' things happening in the COBOL space. Out of interest, does anyone know if new COBOL specs add any major language features or are they just low-profile security fixes and things.
While the article is very "matter-of-fact" about the sunset period and what it means to those that still use Python 2, I'm still surprised that it's taken this long to finally close support. I had assumed that their approach would be to fork the language into a new language (call it something like Liasis) and to allow one of the big-name contractors that specialise on Python 2 to take ownership of it. As an aside, a…
You can count your blessings. I think I know what company you’re talking about, and as far as I know they have no inclination to ever port anything. It’s the sort of company with enough money to pay to have their own runtime, simply because it’s organisationally easier to throw money at “maintenance” once established, than it is to do a big port or rewrite. Legacy support is a well-paying job, if depressing.
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…
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.
Actually, depending on what action you pin dates to, it was twice as long.
One other thing - you can’t run non-64 bit apps anymore. You can still run Python 2.
Earlier quoted context omitted.
Many systems still run COBOL today The latest official COBOL spec is COBOL 2014 and there are at least two or three competing companies out there that will happily sell you up to date COBOL tools and compilers. So while COBOL may be old, there are still new 'exciting' things happening in the COBOL space.
> there are still new 'exciting' things happening in the COBOL space. Out of interest, does anyone know if new COBOL specs add any major language features or are they just low-profile security fixes and things.
Honestly speaking this EOL was made clear almost 6 years ago. If you are still on 2 you are probably best left to your own devices. 6 years is way way more than enough time
More like 12 years by now :-)
> 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…
I honestly don't believe that many will step up and take over. Many will complain, but few will do the actual work. Even if it's just security fixes, there's still the process of testing and release management, and honestly, I don't blame the core Python team for no longer wanting to do release management of both Python 2 and 3.
It was also posted in this thread below by the current maintainer of the project but for some reason that comment was downvoted to [dead].
By reading a bit around about it, i do get the impression that the Tauthon developers face a bit of hostility from the Python community, so i'm not sure how viable it'll be in the long term. I suppose it depends on how stubborn the Tauthon developers are :-P