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

181–190 of 286 posts

Re: Extend Python 2.7 life till 2020

#181

Post by claystu »

lucb1e wrote: post #51

This seems weird to me. Won't this cause a fork in Python at some point, where the 2.7 developers continue on 2.8 or rename it entirely, and another fork continues on what is now Python 3?

That was my first thought too.

Who knows where 3.x will be in 6 years, but now a huge number of people will continue to develop in the 2.x series with no worries. Six years feels like a long time when you're at the beginning of them. By the end, maybe it will be easier to just tweak the Python 2.x codebase than switch everything to 3.x.

Re: Extend Python 2.7 life till 2020

#182

Post by heinrich5991 »

jimmaswell wrote: post #178
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…

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.

Re: Extend Python 2.7 life till 2020

#183

Post by sho_hn »

sillysaurus3 wrote: post #179
sho_hn wrote: post #175

Earlier quoted context omitted.

> It's not about the language. It was for the OP. Can't fault me for my reply not reading on an argument you make after the fact :). > I use Python 2 because of the massive ecosystem of libraries that have been written, work, and will continue to work. I too like useful libraries that save me time and effort, and I agree that Python 2 is extremely strong there. I feel like Python 3 is catching up and has a pretty goo…

I didn't mean to be rude. I'm sorry if it sounded that way. I think it's both shortsighted and irresponsible to force people to abandon libraries that work. The parent poster wasn't concerned about learning the language. They were concerned about dependencies that work, which is what I was saying: "I care about getting my python script working as soon as possible and for a foreseeable future - I couldn't care less fo…

> The parent poster wasn't concerned about learning the language. They were concerned about dependencies that work

No, read more of the thread - to quote the OP:

> I rarely write anything high language besides small scripts.

OK, so you could argue that their scripts probably remain small because they call into tons of third-party code, but honestly I get the impression that it's a case of working with the included batteries and not being overly concerned with dependencies. If it was solely about deps availability, they probably wouldn't have talked about "learning Python 3" as their sticking point.

Re: Extend Python 2.7 life till 2020

#184

Post by kmike84 »

benselme wrote: post #152
kmike84 wrote: post #113

Earlier quoted context omitted.

Alternatives don't help when some other project depend on a package that is not fully ported. And this is a problem. It is still a bit harder to quickly build something using Python 3.x. Check trending Python repos for this month: * portia doesn't work in 3.x because of scrapy, twisted and scrapely; * psdash - developers don't care; * jasper-client - developers don't care; * ansible - Paramico was not ported when dev…

* psdash developers don't care ? then why is this: https://github.com/Jahaja/psdash/commit/f05c8e0a1011603d5ef4... * Twisted is getting ported. Scrapy too, according to the FAQ. * Beets ? http://beets.radbox.org/blog/py3k.html * PyJVM ? Who cares ? My point being, the whole community is moving forward.

Cool about psdash, the commit didn't exist when I started to write the comment :)

Twisted and Scrapy are getting ported, and the community is moving forward. But this is not happening because of a miracle - people are making it happen. My point was not that Python 3.x is bad (I think it is good), it was that community still needs help, that writing alternative software is not the best way to do it, and that there are still reasons why writing new Python 2.x code is easier.

Praising 3.x won't make users switch if they need some unported package, and bashing 3.x won't make other people's lives easier either. So let's help twisted, scrapy and other modules to become 3.x compatible.

Scrapy reached an important milestone recently - its test runner can now run tests under Python 3.x; test runner was the main reason why porting haven't really started before. If anybody wants to help then ping me kmike84 at gmail.com, or check https://github.com/scrapy/scrapy/pull/682, or go to ScrapingHub booth at PyCon and talk to people there.

Re: Extend Python 2.7 life till 2020

#185

Post by dragonwriter »

jimmaswell wrote: post #173
dragonwriter wrote: post #85

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

can't use print x anymore, which also gets rid of "print x,", which printed something without making a newline, for one thing.

> can't use print x anymore

Yes, its a function not a statement, so its now print(x).

> which also gets rid of "print x,", which printed something without making a newline, for one thing.

Sure, you have to do: print(x,end=' ')

if you want to space separate things printed on separate code lines on the same output line.

Of course, if the extra keystrokes bother you, its really not much one-time cost to toss together a library that provides a function that gets rid of them, while keeping the rest of the power of the print function:

    def p(*args, **kwargs): 
        kwargs = {'end': ' '}.update(kwargs)
        print(*args,**kwargs)
Though if I was going to bother to do that, I'd probably do it with the same separator for multiple items on the same line as for items on different lines:

    def p(*args, **kwargs): 
        kwargs = {'sep': ' ', 'end': ' '}.update(kwargs)
        print(*args,**kwargs)
or, further leveraging print-is-a-function:

    import functools

    p = functools.partial(print, sep=' ',end=' ')

Re: Extend Python 2.7 life till 2020

#186

Post by kazagistar »

a1a wrote: post #50
pfraze wrote: post #42

Earlier quoted context omitted.

That's not a valid reason to avoid making the switch. A big backlog of code that you can't afford to port is valid; it's a business issue. But you? This is a tool of your trade, just do the research.

"Tool of your trade": I have no use of python 3, nor do I have any use for Scala, Perl, or whatever. These could all be considered "tools of my trade". I rarely write anything high language besides small scripts. Python 2 does the job. If I ever were to need functionality of another language, great, it's fun to learn something new. Our time is limited and we must prioritize. Sadly we cannot invest time to learn every…

It will take you an hour at most to read up on all the significant changes in Python 3. Its not like learning Scala or Perl at all. It just cuts some things that have been depreciated for years, makes everything more consistently iterable, adds some nice new comprehensions and literals, modifies certain bits of metaprogramming, and a few other smaller changes. The hardest thing for me was remembering that print is a function in 3, and needs parens.

Re: Extend Python 2.7 life till 2020

#187

Post by BoppreH »

jimmaswell wrote: post #178
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…

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.

I disagree. A strong type system is good, but in this case pragmatism wins the battle. I personally have been bitten innumerous times by bugs where division was rounded down (usually to 0, which is especially destructive).

Most of the numbers I encounter start as integers and most of the calculations I need are floating-point. This language behavior saves me from sprinkling "* 1.0" everywhere on my code, or from introducing extremely subtle bugs.

And the integer division is always there, one character away:

    print(1//2 * 1000)   # 0

Re: Extend Python 2.7 life till 2020

#188

Post by kmike84 »

rspeer wrote: post #166
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…

NLTK's situation isn't as bad as it looks. I use NLTK 3.0a, which does support Python 3, all the time. I suppose they're not officially releasing it because there may be some unloved corners of the library that don't work yet on Python 3. But everything I've done with it has worked fine.

That's great that you use NLTK3 and Python 3.x and it works fine! There are no known Python 3.x incompatibilities. But if you find something then please report it.

Issues that prevent a release are not related to Python 3: check https://github.com/nltk/nltk/issues?milestone=2&state=open, https://github.com/nltk/nltk/issues?milestone=3&state=open and https://github.com/nltk/nltk/issues?milestone=1&state=open.

Re: Extend Python 2.7 life till 2020

#189

Post by sp332 »

overgard wrote: post #130

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 think that's also a lesson for the people who are unhappy with the changes. People grumble quietly and just decide not to use the new versions, so the devs have no idea how many people like or dislike each change.

Re: Extend Python 2.7 life till 2020

#190

Post by coldtea »

Pacabel wrote: post #110
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.

Where exactly do you get this "tens of thousands" number from?

From the number of Python programmers out there and the percentage using Python 2.

In fact there'd be "tens of thousands" websites made with Python alone (Django et al), so the number of apps in total will be much higher.

Heck, people doing scientific Python are more than 10.000, and they write more than one new apps for their research every year.

Post reply on HN