Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 2 will be replaced with Python 3 in the next RHEL major release

access.redhat.com

Post reply on HN
Print view View original

271–280 of 341 posts

Re: Python 2 will be replaced with Python 3 in the next RHEL major release

#271

Post by takeda »

exabrial wrote: post #217

As someone completely ignorant in everything python... can someone explain why Python 3 has never replaced Python 2?

Because Python 3 existed for 10 years now, and a lot of new Python 3 features were backported to 2.7. In fact all new features in 2.7 were copied from Python 3. People essentially said, "why should I migrate to Python 3 when it doesn't offer anything new and I don't care about unicode at all (in fact I like when I have to explicitly state what's unicode and what's not)"

Only after PSF declared in 2015 that 2.7 is maintenance-only and won't get any new features Python 3 picked up.

Many people say that reason for this is breaking changes, but the truth is people are lazy and they won't do extra work to convert until they get kick in the butt. Other languages did have breaking changes and people move on, because the old version was deprecated.

With Python for a long time not declaring EOL for 2.x people assumed 3.x will never happen and started resisting it. The FUD started and people were afraid of even trying it. It got to the point that someone was planning to release Python 2.8 that would backport all changes from Python 3 except unicode.

Re: Python 2 will be replaced with Python 3 in the next RHEL major release

#274

Post by pbreit »

dajonker wrote: post #3

This is good: - Python 2 support officially ends somewhere in 2020 - most popular packages are now compatible with Python 3 - Python 3.7 performs about as well as 2.7 with future release expected to be better Although it still took way too long, if you consider Python 3.0 was released about 10 years ago.

Does this whole thing qualify as a "debacle"? Why not a stronger effort at backwards compatibility? Certainly not to maintain performance, correct?

Re: Python 2 will be replaced with Python 3 in the next RHEL major release

#275

Post by X-Istence »

oblio wrote: post #148
dagw wrote: post #127

Earlier quoted context omitted.

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.

The C api isn't the blocker for removing the GIL. The blocker is that Python is a dynamic language and there is no good way to know if another thread has just changed the underlying function on an object or not without having fine grained locking.

Fine grained locking works, but is expensive for non-multithreaded applications and slows down Python. It would speed up multithreaded applications though.

Re: Python 2 will be replaced with Python 3 in the next RHEL major release

#276

Post by arc_of_descent »

compuguy wrote: post #228
dajonker wrote: post #3

This is good: - Python 2 support officially ends somewhere in 2020 - most popular packages are now compatible with Python 3 - Python 3.7 performs about as well as 2.7 with future release expected to be better Although it still took way too long, if you consider Python 3.0 was released about 10 years ago.

Ansible still doesn't support Python 3....

I use Ansible via the API. I want to do it Python 3. I moved the ansible directory from /usr/local/python2 ... to /usr/local/python3 and then squashed out any bugs by hand.

It works! I'm using Ansible via the API in Python 3!

Re: Python 2 will be replaced with Python 3 in the next RHEL major release

#277

Post by eikenberry »

pavelbr wrote: post #200
coliveira wrote: post #48

I 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.

Perl6 isn't an update to Perl5. It's a completely unrelated language with a misleading name.

You could easily argue the same is true with Python2 and Python3.

Re: Python 2 will be replaced with Python 3 in the next RHEL major release

#279

Post by Zeklandia »

tibbon wrote: post #278

I'm a Rubyist. Why are Python users so doubled down on keeping on with Python 2? I can't imagine using Ruby 1.8.x at this point, and even older versions seem well outside the realm of consideration.

There are a few major convention changes, most notably that print is now a function and must be formatted differently to work. People are using libraries that aren't being updated because some people don't want to go update their old work, especially scientists who made the libraries as part of a paper years ago and haven't touched it since.

Re: Python 2 will be replaced with Python 3 in the next RHEL major release

#280

Post by username223 »

jerf wrote: post #171
oblio wrote: post #64

Earlier 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…

"I say this because I'm a bit worried that long term Python has locked itself into a corner where it will keep getting pushed into as the other languages develop a better developer UX." You can stop worrying. That is absolutely what will happen. But it is a good thing. Languages should be something, not merely an accumulation of every fad and trend that appeared over its lifetime. That means eventually they will matu…

> [Languages] will mature, and eventually hit a peak, and then fade.

"Maintenance mode" should be a badge of honor: you have created something that is a stable foundation for new things. For example, how many programming languages are implemented in anything other than C and/or themselves? Not a lot, and that's a huge compliment to C. Despite its faults, you can probably count on your C program working after you're dead.

Post reply on HN