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

221–230 of 286 posts

Re: Extend Python 2.7 life till 2020

#221

Post by melling »

Pacabel wrote: post #219
coldtea wrote: post #190

Earlier quoted context omitted.

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.

Oh, I see. Some people here misinterpreted what I wrote to suggest that Python isn't widely used. Clearly that's not what I meant. I just dislike how melling basically pulled a number out of his ass, and then used it as "evidence" to back up his claims. I wouldn't even consider it a low-quality estimate, since he doesn't even try to justify or explain how that number was obtained. In this case, "tens of thousands" co…

No, I picked what I thought would be a lower bound. Do you think it will only be a few hundred or few thousand over 6 years? Python is an extremely popular language.

Re: Extend Python 2.7 life till 2020

#222

Post by yuhong »

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…

> which AFAIK depending on how much you pay them they support for 13 years

10 years actually. This is a common misconception from those who do not read the lifecycle page carefully.

Re: Extend Python 2.7 life till 2020

#223

Post by BoppreH »

jimmaswell wrote: post #216
BoppreH wrote: post #187

Earlier quoted context omitted.

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 intr…

I just think it's nuts that we're upcasting ints to floats implicitly. Explicitness over implicitness is one of Python's guidelines.

Python3's '/' operator is different from Python2's '/' operator. This is clear when you try to overload them. Python2's is called '__div__', while Python3's is '__truediv__'.

The Python3's operator '/' (on numbers) is defined to return a float, and it'll convert any integer parameters as required. The same is true for other operators, like 'True + True' being 2.

Because of these definitions, you should consider the operators as explicit conversions. 'total / sum' is less explicit than 'total / float(sum)', but still clear enough.

And about guidelines, there are others that fit this case:

    Simple is better than complex.
    Flat is better than nested.
    Readability counts.
    [...] practicality beats purity.
PS: I think you made an important argument and I'm glad you did it, even though I disagree with it. I fail to see why you are getting downvotes.

Re: Extend Python 2.7 life till 2020

#224

Post by andreasvc »

jimmaswell wrote: post #216
BoppreH wrote: post #187

Earlier quoted context omitted.

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 intr…

I just think it's nuts that we're upcasting ints to floats implicitly. Explicitness over implicitness is one of Python's guidelines.

I think it's better to think of it as division being an operation that returns the appropriate type for the operation, i.e., a float where necessary. The type of the operands remain unchanged so "upcasting" is not applicable if you ask me.

Re: Extend Python 2.7 life till 2020

#225

Post by meowface »

pornel wrote: post #193
berberous wrote: post #111

Earlier quoted context omitted.

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

As a Python developer, usually this isn't a major problem for me when going out and finding libraries. Almost every library you find will support 2.7, so I pretty much stick to 2.7 when using or writing any code. I miss some of Python 3's good features but the library ecosystem is more important to me.

It's a real pain in the ass when I try to publish my own, though. The generally accepted rule is that all libraries must support 2.6 through 3.4, and this can be a major hassle.

Re: Extend Python 2.7 life till 2020

#226

Post by jimmaswell »

BoppreH wrote: post #223
jimmaswell wrote: post #216

Earlier quoted context omitted.

I just think it's nuts that we're upcasting ints to floats implicitly. Explicitness over implicitness is one of Python's guidelines.

Python3's '/' operator is different from Python2's '/' operator. This is clear when you try to overload them. Python2's is called '__div__', while Python3's is '__truediv__'. The Python3's operator '/' (on numbers) is defined to return a float, and it'll convert any integer parameters as required. The same is true for other operators, like 'True + True' being 2. Because of these definitions, you should consider the o…

I guess I don't mind it that much.

I went to check out the operation and it seems a on two ints returns an int if the power is a nonnegative int, and a float if it's negative nonzero, in both 2.7 and 3. I didn't expect this kind of inconsistency from python, really.

    >>> type(2 ** 1)
    
    >>> type(2 ** -1)
I guess it does follow the last line of the guidelines there, though. Looking at this power example, the division returning float now is actually an increase in consistency.

Re: Extend Python 2.7 life till 2020

#227

Post by jimmaswell »

SoftwareMaven wrote: post #176
jimmaswell wrote: post #173

Earlier quoted context omitted.

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

print(x, end='') Not quite as nice, but not exactly unusable. https://docs.python.org/3.1/library/functions.html#print

It's a lot less "pythonic".

Re: Extend Python 2.7 life till 2020

#228

Post by PhantomGremlin »

SEJeff wrote: post #151
SEJeff wrote: post #8

Python 2.7.7 aka the Duke Nukem Forever edition!

Gotta say I'm shocked the HN crowd downvoted this.

Really? Or are you being sarcastic? For the most part the HN crowd thinks like Kay from Men in Black: "No, ma'am. We at the FBI do not have a sense of humor we're aware of."

Slashdot has always highly valued humor. "+5 Funny" is a highly sought after moderation. So, perhaps in reaction, HN usually downvotes attempts at humor.

Neither approach is "better". It's just how the respective communities have evolved.

Re: Extend Python 2.7 life till 2020

#229

Post by shitgoose »

calroc wrote: post #168
ubernostrum wrote: post #160

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.

No you are not alone. But you are minority. Majority sees the language not as a tool to solve specific problems, but as a goal, i.e. a way to chase its own tail endlessly. Hence the rudderless pursuit of new. The whole industry is in ADD mode - they moment they create something useful, they discard it and start a new quest.

Re: Extend Python 2.7 life till 2020

#230

Post by Pacabel »

melling wrote: post #221
Pacabel wrote: post #219

Earlier quoted context omitted.

Oh, I see. Some people here misinterpreted what I wrote to suggest that Python isn't widely used. Clearly that's not what I meant. I just dislike how melling basically pulled a number out of his ass, and then used it as "evidence" to back up his claims. I wouldn't even consider it a low-quality estimate, since he doesn't even try to justify or explain how that number was obtained. In this case, "tens of thousands" co…

No, I picked what I thought would be a lower bound. Do you think it will only be a few hundred or few thousand over 6 years? Python is an extremely popular language.

I really do not know. I prefer not to make specific guesses, even lower-bound estimates, when there is insufficient information available.
Post reply on HN