It's for system use. You should never depend on the vendor-supplied compilers for anything, because their goals are different from your (the developer/application-wrangler's) goals. Always develop in a defined, controlled virtual environment, period. If you want be stylish, there's a fancy new thing called a container in which you execute your application in defined, controlled environment. :-)
Python 2 will be replaced with Python 3 in the next RHEL major release
141–150 of 341 posts
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#142Earlier quoted context omitted.
The 2to3 tool will rewrite it automatically. It's not something that requires manual intervention.
Oh ho ho, it is _not_ that simple. Any code with a lot of assumptions about text encoding or integer division is going to be terribly broken after 2to3. It very much does require manual intervention unless you're doing very simple scripts.
Sure but the 2to3 tool allows you to run the tuple_params fixer on its own. Text encoding and integer division are separate issues and have nothing to do with unpacking tuples in function arguments.
My point in this conversation has been that this feature doesn't require manual rewrites. And I'd add that in any case the deprecation period for python 2 will have been 12 years once Python 2 reaches EOL. That's plenty of time to update a code base.
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#143Earlier quoted context omitted.
Wasn't there a big brouhaha over the change from VB6 to VB.Net? The big difference there is that if it's ordained from your corporate overlords, you have little choice, whereas you feel like you've got a bigger right to complain when it's "just" coming from the BDFL.
VB.NET is a totally new language almost unrelated to VB6. That’s like talking about C vs C++, not py2 vs py3.
Calling it a “New language” flatters Vb.net. In reality, it was a “marketing compatibility shim” on top of C# to help VB developers acclimatise to the CLR.
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#144Earlier quoted context omitted.
Half of the problem you mention are either: - if you tried to support Python - if you tried to support Python But nobody used 3.0, 1 or 2. And supporting 2.6 is like supporting ruby 1.7 and 1.8 and 1.9. Which nobody did. And it's easy to rewrite libs when really the language started to be used in 2004. Or maybe not, given that "gem install" still regularly crashes on anything other than the top 20 packages, so it's s…
Python 3.0 came out in 2008 and 3.3 came out in 2012. Are you really saying that nobody used Python3 for the first 4 years of its existence? I was certainly using 3.1 and 3.2 back then.
Pretty much yes. Some Linux distrib where still using 2.6, and not a lot of them had even 3.2 in their packages.
Only a few like you and me tried it.
I can't recall of any big project or lib ever supporting < 3.3.
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#145Earlier quoted context omitted.
It already does ~ ls -las /usr/bin/python 0 lrwxrwxrwx 1 root root 7 Jan 5 02:36 /usr/bin/python -> python3
What distribution are you on? My latest (!) stable Fedora still points at py2: ~ $ ls -als /usr/bin/python 0 lrwxrwxrwx. 1 root root 7 Mar 14 14:36 /usr/bin/python -> python2*
As far as I know, ArchLinux is the only distribution where python points to python3 (and IIRC the change predated PEP394)
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#146They're two different languages. I don't see why python3 "replaces" python2 anymore than say ruby does. IMO they should have separate namespaces and invocation.
They do -- it's trivial to have python2 installed on the same system as python3. The deal with RHEL is that they will no longer include python2 packages at all. That isn't really to say that somebody else won't make packages.
>The deal with RHEL is that they will no longer include python2 packages at all.
Generally, if you are installing your own application you will use a virtualenv with all the packages closed off from the base operating system and dependencies installed with pip (we're all doing this, right folks!?).
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#147I think this has been the ugliest, most badly managed update for a major language since Perl6. And this is not completely over, yet. Over the next 5 years I still expect to see people complaining about this Python3 thing. I hope the designers have learned a lesson.
People used to complain about the way Python changes were breaking their code. So it was decided to restrict all the non-reverse compatible changes to a separate version called 3 and to stop breaking things in 2. That probably allowed Python to become more popular than it would of otherwise, but at the cost of a significant fork.
So what are you going to do? Either way has downsides.
And it isn't like developers really have a lot of power to guide the course of a language. Lua is an excellent example of this. If you want to write a Lua program you probably want to target version 5.1 . The developers have released 5.2 and 5.3 but uptake has been fairly minimal and it's a problem because 5.3 is a Python3 like fork. You can lead but that doesn't mean that anyone will follow. The Python 3 thing could of gone a lot worse (or better) depending on what you think of Python 3.
Ultimately the issue is that different people have different ideas about where a language should go (if anywhere) and no faction of developers or users have ultimate control. It isn't anyone's fault, it is everyone's fault.
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#148Earlier quoted context omitted.
I think Python 3 was not brave enough, to be honest, to future proof Python: * an optional type system without hacks was not introduced (types in comments, really?) * the GIL was not removed or at least a solid parallelism story was not included, one that would allow Python to use all cores on a system while sharing, if needed, memory * no true performance improving changes were made; by this I mean stuff that improv…
the GIL was not removed or at least a solid parallelism story was not included Not for lack of trying. People have been trying to do this since at least python 1.4. They just haven't found a way of doing it without negatively affecting single threaded performance, which Guido considers an unacceptable trade-off. http://pyparallel.org is probably the most interesting latest experiment in this field, but it never got c…
They were breaking many things, maybe they should have rewritten the C API? From what I remember that's the blocker.
That would have broken all C extensions, but it's not like Python 3 at launch was a raving success regarding library porting.
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#149Earlier quoted context omitted.
Is now 'ignoring security' the free pass that is thrown into every argument against opposing positions? I'm being facetious about that; but you know that security risks can be reasoned and mitigated with different means (sometimes less costly) than simply upgrading software.
Companies who cannot upgrade their codebases are companies who cannot maintain their codebases. Eventually, the technical debt hurts your ability to deliver with both speed and safety. When your org can't do that, your org stops being competitive in the market, and if the market doesn't kill your company then the brain drain will. (small and non-notable exceptions for the literal handful of types of orgs where this i…
True, but is there a situation where upgrading will hurt instead of benefit?
Not every solution is just as good for everyone. Think of the delayed upgrade game that some people play. They wait for others to upgrade first to get rid of new bugs at their expense. Now take this game at a 10 year extreme.
For them, the new branch (e.g. new language etc.) is simply too risky. It's not that they are not smart to upgrade, they simply have different opinions on what is valuable than you do.
It
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#150Earlier quoted context omitted.
Is now 'ignoring security' the free pass that is thrown into every argument against opposing positions? I'm being facetious about that; but you know that security risks can be reasoned and mitigated with different means (sometimes less costly) than simply upgrading software.
s/security/bug I don't think that centos 6 is bug free yet it EOL in 2010 too. Actually i'm using it right now and I'm positive it has at least one bug when running in virtualbox. My client won't upgrade. They pay support, expensive support, to keep their old version. In 2020 I'll open a shop to convert old Python code bases or fix bugs in them. I'll charge 4 times market rate. For me it's a net win that people don't…
More power to you, but my initial argument was contingent on "for your definition of works".
Eventually, your client will see that money spent on maintaining old (more appropriately rusty) packages will better be spent on upgrading.