Python 2 will be replaced with Python 3 in the next RHEL major release • Hacker News Board

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

#331

Post by mratzloff » Thu, Apr 12, 2018, 8:26 PM UTC

hartator wrote: post #199

sametmax wrote: post #113

Earlier quoted context omitted.

Swift 3 is compiled. So you can provide the binaries and be ok. Ruby 1.9 is a great example of why you should not be too nice: they told everybody "you have a fews months, deal with it". The community moved. Python said "poor things, we understand, take those tools and years to do the thing", and the community cried, and did nothing. PHP literally failed. They canceled V6 and jumped to V7. The funniest part ? None of…

Comparing Python and Ruby upgrades is not fair. Ruby 1.9 was working mostly the same as 1.8 while provising 2-3x speed improvment, and new exciting features. Python 3 breaks even the basic Python 2 hello world, everything was notably slower, and not anything new and exiciting feature-wise apart ubified string support.

Yes, Python really botched it.

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

#332

Post by mratzloff » Thu, Apr 12, 2018, 8:30 PM UTC

sametmax wrote: post #113

mratzloff wrote: post #106

Earlier quoted context omitted.

I don't know if HN can find any counter-examples, of a language that thrived through an incompatible, code-breaking upgrade. Of course. Swift 3 is one example. Ruby 1.9, as others have pointed out, is another. PHP is yet another, and perhaps more relevant because it is close to contemperaneous. It had its "Python 3 moment" with the migration to PHP 5. Lots of BC breakages.[0] That transition took about 3-4 years for…

Swift 3 is compiled. So you can provide the binaries and be ok. Ruby 1.9 is a great example of why you should not be too nice: they told everybody "you have a fews months, deal with it". The community moved. Python said "poor things, we understand, take those tools and years to do the thing", and the community cried, and did nothing. PHP literally failed. They canceled V6 and jumped to V7. The funniest part ? None of…

PHP 4 to 5, which was what my comment was about, took a middle path and had success much faster than Python did.

Given how much you like Python, I'm surprised at the gall to argue that Python had more technical debt to clean up than PHP did.

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

#333

Post by aoeusnth1 » Fri, Apr 13, 2018, 5:17 PM UTC

rspeer wrote: post #219

SlowBro wrote: post #154

Earlier quoted context omitted.

2.X would still be included as an optional package, correct? I couldn’t determine that from the link, but it seems like RedHat’s practice. Or, they could install it from source. If so, 2.X users still have two years or so to migrate. That’s plenty of time in my opinion, even when all of your code is 2.X. There’s even a library for it.[1] [1] https://docs.python.org/2/library/2to3.html

2to3 is a bad and outdated tool, please don't recommend it. You want http://python-future.org/ .

Thanks for posting this, I didn't know about python-future.

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

#334

Post by Too » Sat, Apr 14, 2018, 6:40 AM UTC

icegreentea2 wrote: post #126

raverbashing wrote: post #29

Earlier quoted context omitted.

Got a source for the performance regressions? Some things are faster in Python 3 than 2 "Most popular" packages, which ones? Most moved a long time ago to Python 3

Here's some light benchmarking (this was posted a few weeks ago I think...) https://hackernoon.com/which-is-the-fastest-version-of-pytho... Basically once 3.7 is out (which is soon), CPython3 will finally be broadly faster than CPython2.7. Interpreter startup time is still annoying though. I really wonder what the right strategy for addressing that is. Like honestly 2.7 is faster than 3.x, but 2.7 CLI tools still fee…

If you are doing raw number crunching you shouldn't be using python in the first place, the whole idea of python is that it makes it easier to write better algorithms lowering your big-O, or use python for the lightweight orchestration and call into native processing libs or external processes such as numpy for the heavy lifting. Same goes for distributed computing which is becoming much more popular; asyncio, await, and other improvements from py3 makes it easier to write fast and robust distributed code, improving your overall application performance.

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

#335

Post by Too » Sat, Apr 14, 2018, 7:09 AM UTC

ceronman wrote: post #325

hyperpallium wrote: post #198

Earlier quoted context omitted.

Could someone provide a summary of the kinds of mistakes/remedies?

One mistake was providing 2to3 as a migration path. This required projects to move completely from 2 to 3, for libraries it meant that they had to either stop supporting 2 (which were the majority of their users) or forking and maintaining both versions. The remedy was to make it possible for libraries to be both 2.7 and 3.x compatible, using tools such as six.py and making some changes to 3.x to make it more compati…

The problem with six is that once you decide to use it your entire code base must be written with the lowest common denominator in mind, in this case py2.7. You can't use six.py at the interface boundaries and nice python3 features inside your implementation. Six is only useful for old 2.7 libraries that want to quickly be 3.x compatible and still maintain their 2.7 compatibility, not if you have an old 2.7 application and want to incrementally add 3.x features.

The proper way make a major breaking change like python did is to provide a bridge between the two versions, so you could import 2.7 modules from 3.x applications, and even the other way around. As of today there is still no such thing.

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

#336

Post by physicsguy » Mon, Apr 16, 2018, 9:44 AM UTC

kalefranz wrote: post #165

physicsguy wrote: post #159

Earlier quoted context omitted.

You can install things with pip but you have to be really careful, because Conda tries to do clever things to avoid downloading multiple copies, which is what you end up with in Virtualenvs. So, if you have two environments both using the same version Jupyter version, installed with 'conda install jupyter' it will only have one copy which is symlinked into the environments. Problem is, if you do 'pip install' in one…

The pip that conda and conda-forge install now have a two-line patch that fixes this. Newly fixed within the last month or so. (It's in our queue to push it further upstream.) Just make sure you `conda update pip` instead of `pip install -U pip` and you'll be fine now.

That's really great to know!

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

#337

Post by raiph » Tue, Apr 17, 2018, 2:03 AM UTC

peteretep wrote: post #65

labster wrote: post #34

Earlier quoted context omitted.

Perl 6 is a completely new language, but that doesn't mean it's incompatible. Inline::Perl5 provides a rather extensive compatibility layer with Perl 5: https://github.com/niner/Inline-Perl5

By this logic, Perl is also compatible with the many other languages for which there are Inline:: modules.

The Perl 6 Inline::Perl5 automatically maps Perl 5's syntax, object system semantics, exceptions, etc. to Perl 6's so that Perl 6 users don't in principle have to know about Perl 5, just the logical API of any used module/library/function.

I don't think the Perl 5 inlines do this.

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

#338

Post by nrser » Tue, Apr 17, 2018, 10:43 AM UTC

bastawhiz wrote: post #328

nrser wrote: post #291

Earlier quoted context omitted.

I think that he's kind of right about the problem. In my opinion, Python's primary business value has been that sweet spot it occupies. It's not the most fun, but it's pleasant. It's not the fastest, but it's not too slow. It's not great on resources, but it's not too bad either. Good people will work with it, and they tend to be the "let's not get creative, let's just get it done" folks that businesses love. Mediocr…

> But if I was running a Python team that had been effectively just trying to get the job done in 2.7 for over a decade I would have to admit that I wanted to switch for my own sake - I think it would be unlikely to make them that much more happy or productive. Part of being a software engineer is keeping your environment up to date. Sure, I could keep using Node 0.10. But I'll get no updates for security or fixes fo…

I'll just say this... I still have 2.7 as my base install... for Ansible. Because they haven't switched yet.

Ansible is owned by... Red Hat. They acquired it in late 2015.

Seems like Red Hat - the people in the post that we're talking about that are shoveling folks off 2.7 - has been neglecting one of the fundamental ongoing maintenance tasks involved in software engineering, and perhaps has something wrong with their engineering culture.

Sorry, this shit is just too funny.

And it seems that Red Hat is booting Ansible from the core repos as well (looks like it's in that depreciation notice!), presumably instead of spending the "two weeks" to update it (you might want to go ask the Ansible team why they're too damn lazy to spend that "two weeks", see what they say).

However, unlink Red Hat and Ansible, some organization depend on the softwares in question, and can't just sideline them 'cause the shit they've successfully run on for a decade-plus has lost it's blessing.

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

#339

Post by b2gills » Fri, Apr 20, 2018, 6:46 PM UTC

bitL wrote: post #222

Avshalom wrote: post #206

Earlier quoted context omitted.

yeah and 90% of business code is also written in COBOL and another 90% in MUMPS, but somehow the world continues to work despite the fact that they've been pining for the fjords for decades.

There is obviously a massive jump from COBOL to Python, and small but annoyingly incompatible step from Python 2 to Python 3. I hope you understand the difference. It's not like Python 3 was the best language ever, it's just a variation (and IMO not that great one to justify breaking backwards compatibility) of the same theme. Ask Perl guys how they liked a similar situation. If I didn't need to use Python, I wouldn'…

A similar situation to Python 2->3 in Perl is from Perl 5.6 to Perl 5.26 with the difference being that Perl maintains mostly backwards compatible.

If you are talking about Perl 5->6 that is more like going from C++ to D. (With a touch of Haskell+Go mixed in)

For several years we have been considering the two current Perl's as sister languages. Both are being actively developed with a yearly stable release for Perl 5 and a quarterly stable release for Perl 6. (Rakudo Perl 6 is mostly written in Perl 6 or subset language, and is also a newer codebase; so it is easier to change without breaking things.)

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

#340

Post by b2gills » Fri, Apr 20, 2018, 7:10 PM UTC

pjc50 wrote: post #24

sorisos wrote: post #10

Earlier quoted context omitted.

Many languages seem to suffer from legacy support. C++ and PHP for example. The double standard might be the only way to avoid this!?

The legacy support is a benefit for people who are still using it. The lesson from both Perl and Python is clear: you cannot remove language features - if you do you're creating a new language which has to start from zero in adoption.

Perl 6 removes very few language features. About the only notable ones I can think of is fork and format. Since Perl 6 has built-in multithreading, fork is not needed. And hardly anyone uses format anymore (it is great for directly printing to a line printer).

What Perl 6 did is change the syntax for various features of Perl 5; while adding a lot of new features.