Live data from Hacker News

Extend Python 2.7 life till 2020

hg.python.org

271–280 of 286 posts

Re: Extend Python 2.7 life till 2020

#271

Earlier quoted context omitted.

It's not about the language. Languages are easy to learn. I can learn one between breakfast and lunch and be productive by dinnertime. I use Python 2 because of the massive ecosystem of libraries that have been written, work, and will continue to work. It's shortsighted and more than a little irresponsible to shame or muscle people into switching. Code that works is valuable. Code that has been tested for a decade is…

^ This is the best comment in the entire thread. Nobody who's making anything that actually matters and delivers value to customers cares about the improvements in the language itself as much as they care about the battle-tested libraries that come with that particular language. If you are a company that actually matters (has significant growth / users) and you use Python3 over Python2 as the main language in your st…

I'm a build engineer at Intel (100,000+ employees), and we strictly use Python3. You act like it's a completely different language. It hurts the community when you blow the situation out of proportion. There are innumerable Python3 libraries, and while there are most certainly more in the Python2 camp, who cares? This isn't a dick-measuring contest; it's a change for the better in a language we all seem to like.

Re: Extend Python 2.7 life till 2020

#272
Years ago, when I first heard about Python 3 and plans to improve the language my first thought was "Yes! Multi-line lambdas are coming!", then I started reading more and found out that Guido actually wanted to _remove_ lambdas all together. I still remember the state of shock I was in after reading that, and a sinking feeling.

The lambdas stayed, fortunately, but, unfortunately, I'm still convinced the whole project was a bad idea. The cosmetic changes which make Python 3 incompatible with Python 2.7 are just not worth the trouble of breaking the compatibility. Has anybody ever tried to estimate the man-hours needed to port the myriads of great Python 2.7 libs to Python 3 and weight it against the advantages of subtle language improvements? I don't think so. Plus, the big Python's problems like GIL are still there in Python 3...

If it was up to me I would drop Python 3 and focus the development effort of the community on improving PyPy and porting libraries to it.

Re: Extend Python 2.7 life till 2020

#273

Earlier quoted context omitted.

^ This is the best comment in the entire thread. Nobody who's making anything that actually matters and delivers value to customers cares about the improvements in the language itself as much as they care about the battle-tested libraries that come with that particular language. If you are a company that actually matters (has significant growth / users) and you use Python3 over Python2 as the main language in your st…

I'm a build engineer at Intel (100,000+ employees), and we strictly use Python3. You act like it's a completely different language. It hurts the community when you blow the situation out of proportion. There are innumerable Python3 libraries, and while there are most certainly more in the Python2 camp, who cares? This isn't a dick-measuring contest; it's a change for the better in a language we all seem to like.

Is Python the main language you guys use, over Java/C++ as well? And what's the context of its usage? How do you deal with stuff that's missing, do you just have your own employees fork and port existing libraries?

I'm not asking as a challenge to you, I'm genuinely curious.

Re: Extend Python 2.7 life till 2020

#274

Earlier quoted context omitted.

Try ANSI C then!

I heard Pascal is all the rage nowadays Or a good, supported, still used and very stable language: Fortran.

Fortran's most recent standard (Fortran 2008, adopted as an ISO standard in September 2010) was actually adopted more recently than the 2.7 release of Python, so, arguably, Python 2.x has been static for longer than Fortran.

(Obviously, if you said, e.g., Fortran 77, the story would be different.)

Re: Extend Python 2.7 life till 2020

#276

I just thought I'd like to know what Hacker News thinks. Will Python 2.x ever die? I'm still writing lots of code with it and even quite a lot of new code. It's been around for ages and it feels like almost no libraries have been ported to 2.x yet. On a couple of occasions I've started a project with Python 3.x just to drop it or move to Python 2.x as a library I need doesn't seem to exist for Python 3.x and I don't…

> Will Python 2.x ever die? My guess would be that Python 2.x will die at the same time that Python dies, i.e. the "transition" to Python 3 will never really happen, and part of the reason that Python will die is the split between 2 and 3. I don't think it was obvious that Python 3 would "fail" in this sense, but it seems pretty likely now. Sympathy with Guido; this is essentially a cultural problem rather than a tec…

They're not going to sort out the mess. GVR is 100% stubborn on having 2 and 3 live alongside each other till everyone moves to 3. He won't be combining them in any way in a Python 4.0 and slowly removing the Python2 stuff.

I personally won't be moving till GAE, Azure, Amazon, PyPy, PyInstaller, and all Linux distros make the jump. Which at this rate appears to be never.

I'm going to do exactly what you're suggesting, and move off of Python entirely at some point. I'm truly amazed that GVR is dancing with death to kill Python over unicode and cruft. I'm hoping Python (2) becomes the community version and 3 remains the experimental branch.

Re: Extend Python 2.7 life till 2020

#277
post #34

This is really disappointing to see - I fear that it will slow adoption of Python 3 even further, when it was just reaching a tipping point[0]. When I first learned Python, I learned Python 3 first because it was newer, and I figured everyone would be using it soon enough. Little did I know that Python 2 would continue to be supported for over ten years after that! Some people make a big deal about figuring out "whic…

On the other hand, if you are comfortable with Python 2, it will do the job, and you know it will be supported for a foreseeable future, why bother learning Python 3? I assume there is a good answer for switching to Python 3, but I honestly don't know (haven't bothered to do any research though). Harshly put: I care about getting my python script working as soon as possible and for a foreseeable future - I couldn't c…

I could have taken that attitude with Django 3 years ago, but they released a new version a week or so after I started using it. That was a simple upgrade, no problems (1.2 - 1.3). I try to stay up to date now, as it keeps many things relevant. Sometimes it causes a bit of hassle.

Now If I had stayed on 1.2, then many of the extra libraries I am using or looking at these days would not be compatible. (Now sometimes I want to use older libraries that have not been kept up to date, but the more popular packages which gain traction - the "more important ones" tend to keep up to date or replaced by ones that do).

A language is different from a framework, but I assume once enough traction is gained, then the same thing will happen with Python - popular packages will end up up on Python 3 only. There seems to be a fair bit of 'push' from the community for people to move to Python 3, with comments of "why not change already".

Re: Extend Python 2.7 life till 2020

#278

Earlier quoted context omitted.

> Well honestly, python 2* is a lot more convenient to write in a lot of ways In what way is python 2 more convenient to write? Outside of the rapidly shrinking set of cases where the best approach to a key problem is addressed by a Py 2 only library -- or the case of "I want to deploy on Google App Engine" -- I don't really see how Py 2 is "more convenient".

On both OSX and many Linux distros, Py 2 comes pre-installed but Py 3 does not. If I'm going to write simple scripts that I'm going to give out to people, it's nice not having to worry about them needing to fuck around to get the script to run.

sudo apt-get install python3. Or Whatever the OSX equivalent is.

Its not that difficult.

Arch comes with Python 3 as default.

Re: Extend Python 2.7 life till 2020

#279
post #180

Earlier quoted context omitted.

> On both OSX and many Linux distros, Py 2 comes pre-installed but Py 3 does not. Because python 3 was not the most stable at the time of distribution of that operating system. Why would I the developer of said operating system release anything but the most stable versions of the language? This would in turn make my operating system at times less stable.

I totally agree. However, until Py3 is packaged standard it's always going to be easier to run Py2 code. For example, I have a friend who does data analysis on OSX and occasionally she gets data in a format that is ugly. I take a look at it and send her a python script that will massage it into something nice. She's ok with the occasional "sudo pip install ..." to get a library, but if my instructions started with "o…

Simple script like that are unlikely to be much different between Python 2 and 3 unless you are using specific libraries. Just make make all the "prints" into "prints()" and "Exeption, e" into "Exception as e", and I can't see what the differences would be.

Re: Extend Python 2.7 life till 2020

#280

Earlier quoted context omitted.

It's not possible to determine the language. The extensions are the same and much of the syntax hasn't changed, and many of the backwards-incompatible differences are subtle. Python2: print(1/2 * 1000) # 0 print({b'a': 'bytes', u'a': 'text'}[b'a']) # text print(b'A'[0]) # A Python3: print(1/2 * 1000) # 500 print({b'a': 'bytes', u'a': 'text'}[b'a']) # bytes print(b'A'[0]) # 65 And the merits of doing a backwards-incom…

Python3's treatment of integer literals in that case is bad. The first is the behavior that someone used to programming will expect by default, since those are integers. If you want non-integer operations you should have to use a decimal point in the 1 or 2.

Looking at that example, the second one looks more correct to me without thinking about it too much.

But if I was writing it I would space the "1/2" into "1 / 2".

The first says half to me (ok, until I pause and realise it is code I am interpreting), while the second is 1 divided by 2.

Post reply on HN