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

Why I'm Making Python 2.8

naftaliharris.com

Post reply on HN
Print view View original

171–180 of 392 posts

Re: Why I'm Making Python 2.8

#171

Post by guitarbill »

jzwinck wrote: post #133
aidos wrote: post #36

Earlier quoted context omitted.

But people that have that csv issue have deeper lurker encoding issues they're probably not aware of. Sure, don't change the stuff that works and cause yourself unnecessary pain, but don't blame python 3 for your misencoded data.

Oh we are perfectly well aware of our encoding issues. In NumPy, one of the most important libraries in Python 2 or 3, strings always take one byte per character. And it's not going to change. So the built in csv module needs to support a reasonable behavior. Which it does not. If a company tries Python 3 and discovers basic things like CSV produce utter gibberish, they would do well to opt out. And they do--in drove…

> So the built in csv module needs to support a reasonable behavior. Which it does not.

It could be argued that the csv module's behaviour is reasonable, and NumPy's isn't. (I'm not 100% sure about all the details of this issue) Hopefully, NumPy will change it's behaviour to match Python 3, but if not you could still use the NumPy CSV routines like `loadtxt` or `genfromtxt` [0]. So then this becomes a documentation change to add some warnings to both modules.

> they would do well to opt out. And they do--in droves.

This is simply not true. They would do well to handle strings properly and so avoid bugs in future - something Python 3 actively encourages, and Python 2 obscures. And while I can't speak for every company, our metrics show that our Python 3 code has far less customer issues than Python 2, Perl, or Ruby. Now that's business value. (Edit: I mean it's hard to make the comparison - the Perl code is e.g. older - but we're writing code now, and when the interns add new stuff to the Python 3 codebase, it breaks less. All of them are still actively developed, and the Ruby one is about as old as the Python 3 one).

[0] https://docs.scipy.org/doc/numpy/reference/generated/numpy.l...

Re: Why I'm Making Python 2.8

#172

Post by guitarbill »

username223 wrote: post #117
beojan wrote: post #79

Earlier quoted context omitted.

This is how you end up still running fixed-format Fortran code in 2016. If your software is being actively maintained, it's time to move to Python 3.

This is how you keep using those efficient, numerically-stable subroutines written by a smart guy who retired 20 years ago in your new code. Unlike Python, Fortran has managed to add significant new features without breaking old code.

Unlike Python, Fortran hasn't seen an increase in usage and hasn't brought the joy(?) of programming to thousands of new programmers in the last 10 years. So sticking to Fortran or backwards compatibility blindly doesn't solve all the problems, either.

Maintenance is key. Most people don't stick around for 20 years anymore either. I know I'm going to have an easier time finding a new hire for a Python codebase. And he's going to have a far better chance at understanding said codebase. Code which nobody knows how to maintain will hurt us either with a fiendish bug, or limit out growth. So for me, slowly moving away from legacy stuff is good business value in the long run.

Remember, you can never be sure that Fortran code is 100% bug free. The test of time is as good as any other test, but not perfect.

Re: Why I'm Making Python 2.8

#173

Post by flaviojuvenal »

SeanDav wrote: post #135
yoz-y wrote: post #20

I make software that people can write plugins for in Python. After months, years of struggle we finally dropped support for Python 2 because our small team could not bear the overhead of maintaining two bindings. We work a lot with researchers in signal processing domain and we have hard time as it is to get people to use Python 3. Please, do not put obsolete software on life support.

> "Please, do not put obsolete software on life support." The vast majority of current development out there is in python 2.x. A small minority use Python 3.x. How on earth does this make Python 2.x obsolete? This is like saying Perl 5 is obsolete, just because Perl 6 is out and completely ignore the realities of the real world use of the products.

Please back your claims with data.

Re: Why I'm Making Python 2.8

#174

Post by vurpo »

jzwinck wrote: post #133
aidos wrote: post #36

Earlier quoted context omitted.

But people that have that csv issue have deeper lurker encoding issues they're probably not aware of. Sure, don't change the stuff that works and cause yourself unnecessary pain, but don't blame python 3 for your misencoded data.

Oh we are perfectly well aware of our encoding issues. In NumPy, one of the most important libraries in Python 2 or 3, strings always take one byte per character. And it's not going to change. So the built in csv module needs to support a reasonable behavior. Which it does not. If a company tries Python 3 and discovers basic things like CSV produce utter gibberish, they would do well to opt out. And they do--in drove…

>In NumPy, one of the most important libraries in Python 2 or 3, strings always take one byte per character.

So I won't be able to use NumPy with either of my two native languages. That sounds like a bit of a shortcoming for the majority of the world.

Re: Why I'm Making Python 2.8

#175

Post by susan_hall »

lloeki wrote: post #33

> And the majority of Python code written does not run under any of the 3.x interpreters. This makes it harder for its users to be productive. What a load of bollocks. For new projects this only matters if libraries aren't ported, which they are for the most part. For old projects, either you're in a situation where you can spend time porting your code to Python 3, or you don't; but as TFA mentioned pep-404, the writ…

I currently work for a client who has decided to shift away from PHP and towards Python. They had a monolithic PHP app with perhaps 250,000 lines of code. Now we are developing a series of Python apps in the microservices style. We've decided to develop everything as Python 2.7. We are not looking at Python 3.x. There are a few reasons. Some libraries that we want are in Python 2.7. And Amazon only supports 2.7. And we are not wild about Python 3.x's attempt to imitate a classical object oriented style.

We would look very closely at a Python 2.8, if it existed.

Re: Why I'm Making Python 2.8

#176

Post by js8 »

masklinn wrote: post #110
js8 wrote: post #104

Earlier quoted context omitted.

Why would you want to downvote somebody trying to help you? In any case, I think I see your problem. You are not the sole user of Python language. There are features that other people like (such as using '*' in unpacking), and so features you like are weighted against their use cases, and a reasonable compromise is made. And frankly, I think if you like to use lambdas that much, you really want to program in a langua…

> Why would you want to downvote somebody trying to help you? Misreading comments is not helping.

That's why I used the word "trying". Maybe you should read more carefully before you want to accuse others from misreading something. ;-)

I think it's unfair to say that I misread his comment - he doesn't explicitly mention he is aware of the workaround I outlined for the functions, and that he is bothered with lack of tuple unpacking in lambda expressions only, not in ordinary functions.

Regardless, I still think it's quite impolite to downvote somebody who wants to help you and misunderstands you, if they are not e.g. factually incorrect. If you don't actually tell me where I am wrong, I cannot improve my answer. Also, this is not Stackoverflow, where that could be marginally acceptable (I am very strongly against downvoting without explanation).

Re: Why I'm Making Python 2.8

#177

Post by kstrauser »

jnbiche wrote: post #126
andy_ppp wrote: post #87

I think the problem for me is that they did these changes and made a big song and dance about Python 3. If they had have called Python 3.0 v2.9 instead everyone would have been clear they had to migrate. PHP has been successfully deprecating features for decades now and cleaned up their code base; they have never had a schism in the way Python has so you can argue all you want about legacy, or people preferring 2.7.…

> If they had have called Python 3.0 v2.9 instead everyone would have been clear they had to migrate. [...] The reason this happend (and is still happening) are human not technical. You know, as a strong proponent of Python 3.* (it's a significantly better Python), I started to write a withering critique of your statements here (and I do strongly disagree about naming it Python v2.9). But then I started actually look…

That's a really good point about the download links. The Python 2 link should be lower down on the page, or perhaps smaller, and maybe labeled "legacy support version" or similar.

To be fair to the "Should I use Python 2 or Python 3 for my development activity?" page, it starts with:

> Short version: Python 2.x is legacy, Python 3.x is the present and future of the language

Re: Why I'm Making Python 2.8

#178

Post by oblio »

coldtea wrote: post #150
oblio wrote: post #109

Earlier quoted context omitted.

Well, in some respects T-shirts made in the 80s are obsolete, even though functionally they still work. Fashion changes, materials change, cuts change, etc. You could still wear them today but you'd be working against today's "protocols".

Actually 80s t-shirts are very much in fashion.

Ok, replace that with 60s or 50s or any other period from which clothing is considered old-fashioned, even for hipsters.

Clothes are "deprecated" or "obsoleted", just like everythihg else.

Re: Why I'm Making Python 2.8

#179

Post by hartator »

We should make this Python 4.0 and move on. Some high paid google engineers working the "official" 3.x will be pissed, but that's life. I am sad to see the schism in Python community.

Re: Why I'm Making Python 2.8

#180

Post by js8 »

dtech wrote: post #158
AnonymousPlanet wrote: post #105

Earlier quoted context omitted.

If you have several large software products rolled out and churning away at hundreds of customer sites, moving from Python 2.x all the way to 2.7 alone is a slow and tedious process of tests and deliberations. And we're still not talking about going all the way to 3.x which breaks things in even more new and exciting ways. So scoff all you want, but Python 2.x isn't going away that soon.

If moving to a 2010 version of your programming language is slow and tedious you're doing something very wrong. In the Java world (conservative and slow-moving) JRE 7 (2011) is considered the absolute minimum, and if you're not targeting JRE 8 (2014) you have to have a very good reason.

> If moving to a 2010 version of your programming language is slow and tedious you're doing something very wrong.

You mean like, dealing with strings and Unicode? That's usually the case why people have trouble migrating to Python 3.

Post reply on HN