Live data from Hacker News

Extend Python 2.7 life till 2020

hg.python.org

191–200 of 286 posts

Re: Extend Python 2.7 life till 2020

#191
post #168

Earlier quoted context omitted.

Well, if you were and are staying on Python 2.7, you are committing to anywhere from 6 (if you start now) to 10 (if you started day of 2.7.0 release) years of a frozen, non-evolving language. No new features, no improvements, nothing -- just the same language, for a decade. If you can live with that, then by all means stick to 2.7 until your Red Hat support contract expires. If not, consider switching to 3.x.

No new features, no improvements, nothing -- just the same language, for a decade. Am I alone in being excited by this? I am figuratively drooling over such stability.

Try ANSI C then!

Re: Extend Python 2.7 life till 2020

#192

This is the path that all dynamically typed scripting languages must follow. Over time, change becomes impossible because the lack of typechecking or static analysis tools means that any change might break something in a subtle and hard-to-diagnose way. And so the language grows by accretion. You end up with something like bash or perl, where there are a million ways to do any one thing. Each way was added at a parti…

The larger problem of 'language drift' seems inevitable- C++ from 15 years ago will have auto_ptr's sprinkled throughout, Common Lisp (compared to Scheme) has had stuff added and added to it, Java has more stuff tacked on as it grows... but it only really causes a problem when you have something like a dynamic language because you're using one interpreter (usually) for the whole project, and so anything breaking backwards compatibility causes huge problems. (Add to that that interpreted languages tend to have more changes in syntax more quickly than compiled languages).

Could dynamic languages avoid this by having (say) a byte-code compiled backwards compatibility module? I would imagine it looking something like this for Lua:

luac -version=5.0 module.lua -o module.o

and then call into whatever functions you need from module.o in the rest of the project, using the new interpreter for whatever doesn't need to use legacy features.

Re: Extend Python 2.7 life till 2020

#193

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…

I chose to learn Ruby in part because of the confusing Python 2/3 issue. I recognize that this is a largely stupid reason to choose a language, but when lots of people suggest that either language is great to pick-up, well, it was another easy reason to lean Ruby over Python.

Having a split like that in a language is terrible. You find libraries that work with not-your-version and you envy features that would make your code cleaner/faster/better, but you can't use them.

- "Ugh, that thing is lacking/stupid/messy."

- "Oh, no problem, that wart has been fixed in Python 3"

- "Can we use it?"

- "No."

Re: Extend Python 2.7 life till 2020

#194

Earlier quoted context omitted.

Python 2.7 hasn't has any improvements since python 3 began, and it won't. All this announcment means is that Python 2.7 will continue to get security/support for another 5 years.

Python 2.7 was released after 3.1 and contains many features backported from the 3.x series in order to ease migration.

Ah, yeah. Sorry, my history is a little hazy. I claim I was going for the spirit of the situation, rather than the details... ;-)

Re: Extend Python 2.7 life till 2020

#195

This is the path that all dynamically typed scripting languages must follow. Over time, change becomes impossible because the lack of typechecking or static analysis tools means that any change might break something in a subtle and hard-to-diagnose way. And so the language grows by accretion. You end up with something like bash or perl, where there are a million ways to do any one thing. Each way was added at a parti…

It is easier. On the other hand, Java doesn't drop any deprecated API's either, so static types may not help as much as you think. Migration still has to happen before dropping something. It seems to be that automatically upgrading your code, even with "go fix", is staying on the hamster wheel. Using a stable language like Python 2.7 is getting off the hamster wheel, since the "hipster" programmers (including me, som…

I would go one step further: in an effort to maintain binary compatibility, Java ended up trying to do "type erasure with generics", which in my mind is a horrible wart. C# went through the same changes, and built two different libraries for collections to accommodate it.

What I am saying is that it wasn't much prettier in those cases, and golang might not have had the same type of issues yet, but it just hasn't been around for all that long.

Re: Extend Python 2.7 life till 2020

#196
I understand that changing to Python 3 can be expensive but really all that any company or person is doing is prolonging the inevitable. If they have a good product/app/etc. that will last it will have to change to Python 3 and sometime in the future, right? Why keep waiting? Why support something that is considered by it's makers to be inferior? I really would like answers to these questions, if someone is willing.

Re: Extend Python 2.7 life till 2020

#197

The lesson here is that it's important to "sell" new versions of anything. You can't just expect people are going to upgrade because it's the new hotness. Older versions of your own software are often your biggest competitor. (See also: Microsoft and Windows 8).

I didn't find it simple to google for what the differences are between 2 and 3. As an outsider to the Python community, that would be very important information to me if I wanted to learn the language. The most immediate answers I got was "use 3 because it's the future".

Re: Extend Python 2.7 life till 2020

#198
post #4

Earlier quoted context omitted.

Guido's or yours opinions are irrelevant. If people have a lot of code for Python 2.7 and have little incentive to migrate to Python 3, then they'll stick with Python 2.7.

I've used 2.* for about 10 years, quite happily. If I switch to anything, I'll probably switch to Go. (I originally typed 2.7, which is nonsense.)

Rewriting your code base is easier then fixing it for 3? That really just sounds like you are being overly dramatic, or looking for an excuse to try something new.

Re: Extend Python 2.7 life till 2020

#199
post #168

Earlier quoted context omitted.

No new features, no improvements, nothing -- just the same language, for a decade. Am I alone in being excited by this? I am figuratively drooling over such stability.

Try ANSI C then!

I heard Pascal is all the rage nowadays

Or a good, supported, still used and very stable language: Fortran.

Re: Extend Python 2.7 life till 2020

#200
post #148

Earlier quoted context omitted.

> 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? This bothers/worries me, because I don't understand where this notion that "learning Python 3" requires significant effort or commitment comes from. Python 3 isn't massively different from Python 2. I learn more "new stuff" (APIs I've never used befor…

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 stack, I'd like to know who you are, if you even exist.

Post reply on HN