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

Extend Python 2.7 life till 2020

hg.python.org

Post reply on HN
Print view View original

201–210 of 286 posts

Re: Extend Python 2.7 life till 2020

#201

Post by al2o3cr »

derefr wrote: post #135
melling wrote: post #56

Earlier quoted context omitted.

Well, the one big reason was that you were going to lose support for Python 2. Guido just took that reason away and now tens of thousands of new Python apps are going to be written in Python 2 because they've got another 6 years to worry about it. Guido just created a bigger problem. No good deed goes unpunished.

It feels like the problem is the black-and-white thinking on the part of developers of every language being either "okay to develop in" or "completely unsupported." If only there was a way to deprecate a language, with the same meaning as deprecating an API method: "it's not gone yet, but it will be soon, so in strict mode using it is an error." (The main problem to solve would be: strict mode of what? The package ma…

"If only there was a way to deprecate a language, with the same meaning as deprecating an API method"

One way that usually works is to release a newer version and stop updating the old one after five years. Oh wait...

Re: Extend Python 2.7 life till 2020

#202

Post by chomp »

lucian1900 wrote: post #75
makmanalp wrote: post #40

I see many comments talking about how this will slow down the migration process. But I don't think the situation is that bad. Most of the py3 wall of superpowers is now green ( https://python3wos.appspot.com/ ) with boto, mysql-python, nltk, python-openid being some of the rare few in terms of not having great py3 alternatives. And most of these have ports on the way already. So one interesting effect of this is that…

Also fabric, supervisor, graphite, gevent, eventlet, Twisted, etc. The list is still too long.

Have no fear, Paramiko supports Python 3 as of 1 month ago:

https://pypi.python.org/pypi/paramiko/1.13.0

Fabric won't be far behind after this.

Re: Extend Python 2.7 life till 2020

#203

Post by mark-r »

heinrich5991 wrote: post #182
jimmaswell wrote: post #178

Earlier quoted context omitted.

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.

The good thing is that you can get that behavior if you really intend it, just use the // operator. I'm really in favor of this change.

Even better is that // has been available in Python 2 for ages, so you can get used to using it everywhere. Evidently they were anticipating this change.

Re: Extend Python 2.7 life till 2020

#204

Post by im3w1l »

BoppreH wrote: post #165
antocv wrote: post #115

Earlier quoted context omitted.

Hm that does sound clever. A preparser to determine what language version then invoke that interpreter. And if the 3 is so good people would switch over to usong its features only very soon. Maybe py3 just doesnt have good enough features compared to 2 for people to make the switch and shouldnr have existed in the first place? But gradually introducing changes. Now python is for all intents two languages instead of o…

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…

What about

import2.7 modulefoo

Re: Extend Python 2.7 life till 2020

#205

Post by rodgerd »

ama729 wrote: post #76
crusso wrote: post #45

I just got back into some Python programming after a 2+ year hiatus from the language. I'm stunned that this 2.x vs 3.x debate is still happening and that 99% of all libraries in use * haven't been converted to 3.x. I like the language, but ... damn... If it weren't for the scikit/numpy stuff, I'd stick with Ruby. The Ruby community seems much less fragmented and wants to see the language move forward. It helps a lot…

> The Ruby community seems much less fragmented and wants to see the language move forward. It helps a lot that the 800 pound gorilla, Rails, keeps up with Ruby releases. You kind of answer your question you know, the reason why Python is so fragmented wrt Ruby is precisely because it has a much larger number of uses case: scientific (numpy/scipy/panda), sysadmin, web (django, bottle, ...), games (Ren'Py, ...), etc.…

> Ruby on the other hand is pretty much just Rails[1]

Puppet and chef say hi.

Re: Extend Python 2.7 life till 2020

#206

Post by BoppreH »

im3w1l wrote: post #204
BoppreH wrote: post #165

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…

What about import2.7 modulefoo

It could work, but can you imagine the extra complexity for the interpreter? It would require extensive type conversions every time an object passes the version barrier, and all the Python3 libraries' classes would have to be backported for compatibility.

And it's not just a matter of sacrificing core dev hours for the greater good, the result would be much slower and full of gotchas.

This is a very creative idea, ingenuously simple, but I don't think it would fly.

Re: Extend Python 2.7 life till 2020

#207

Post by derefr »

al2o3cr wrote: post #201
derefr wrote: post #135

Earlier quoted context omitted.

It feels like the problem is the black-and-white thinking on the part of developers of every language being either "okay to develop in" or "completely unsupported." If only there was a way to deprecate a language, with the same meaning as deprecating an API method: "it's not gone yet, but it will be soon, so in strict mode using it is an error." (The main problem to solve would be: strict mode of what? The package ma…

"If only there was a way to deprecate a language, with the same meaning as deprecating an API method" One way that usually works is to release a newer version and stop updating the old one after five years. Oh wait...

It's the "using it in strict mode is an error" part that's important. Compilers can automatically refuse to compile deprecated-but-not-broken code. What can automatically refuse to let you start a new project in a deprecated-but-not-broken language?

Re: Extend Python 2.7 life till 2020

#208

Post by 6d0debc071 »

knappe wrote: post #133
a1a wrote: post #92

Earlier quoted context omitted.

Nor have I done research on Perl, Scala, etc. Your missing my point. I am successfully getting my things done in Python 2. I do not have any use for Python 3, Perl, Scala, or any other language. I might have in the future, and hey, some language might be better suited to solve the problem - but as long as it's not drastically better the sensible tradeoff is to stick with Python 2.

So much for having a big toolbox with lots of different hammers available to you.

To be fair, most of the people I see with sheds with a load of tools in them don't make much and wouldn't know where to begin if they suddenly had to. It's the appearance of the thing that they love.

Re: Extend Python 2.7 life till 2020

#210

Post by gsnedders »

drewcrawford wrote: post #140

There are a lot of comments here from people who aren't on the python-dev list and don't really understand what this diff actually means. The core developers are not required to maintain 2.7 post-2015, and most of them won't be involved in it. That part hasn't changed. What is happening is that Red Hat is preparing to cut a RHEL 7 release, which AFAIK depending on how much you pay them they support for 13 years. So t…

I'm a few thousand emails back on python-dev, but:

> Meanwhile, there are some large companies that use 2.7 extensively on Windows (e.g. Enthought, Anaconda) and the thinking goes that somebody can probably be found to produce a Windows installer once in awhile, assuming that Python.org will still host a download.

Note that 2.6 had no installers released beyond 2.6.6 (2.6.9 was the eventual last release), so there's a precedent for source-only releases if nobody does want to provide Windows/OS X installers.

Post reply on HN