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

221–230 of 392 posts

Re: Why I'm Making Python 2.8

#221

Post by rajathagasthya »

ianamartin wrote: post #200
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…

The Python Software Foundation has an obligation to defend the trade name. If it fails to exercise it, then it can be denied in the future. I don't expect litigation because that's not how the community rolls. I expect a polite message from gvr to the author asking to change the name. If that fails, the PSF has no choice. It's use it or lose it.

> I expect a polite message from gvr to the author asking to change the name.

And he has - https://github.com/naftaliharris/python2.8/issues/47#issueco...

Re: Why I'm Making Python 2.8

#222

Post by kevin_thibedeau »

ant6n wrote: post #191
mathgenius wrote: post #51

People don't seem to be considering the possibility that a stagnant python 2.7 may actually be a reason to like that version of the language. I must admit it is nice to not have those oh-so-keen python developers messing with my favorite language. However, I recently had a gig working in py3. Apart from screwing up every single print statement for a long time, it was entirely drama-free, and actually pretty great. Th…

why can't print be both a function and a statement...

The print statement has a lot of special magic like '>>' and trailing commas that uglifies the parser.

Re: Why I'm Making Python 2.8

#223

Post by jimnotgym »

guitarbill wrote: post #171
jzwinck wrote: post #133

Earlier quoted context omitted.

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

I moved to Python and got back into coding specifically to work with csv files. And from the first time I used code copy and pasted from SO or wherever to import and export CSV's with Python 3 I have not found that I am plagued by unreliable behavior and mischievous encoding. Yes there seems to be a type conversion necessary with NumPy, but it simply is not true that Python 3 has an endemic problem with CSV files!

In fact, the reason I chose Python was because I was able to dive so quickly into real problems like this with no problems whatsoever.

This is a minor issue for someone porting from 2 to 3, it is not a problem with 3

Re: Why I'm Making Python 2.8

#224

Post by godelski »

RedCrowbar wrote: post #209
coldtea wrote: post #194

Earlier quoted context omitted.

> You keep saying things like this but numbers don't bear that out. What numbers? All the numbers I've seen -- official numbers from PyPY etc) tell otherwise.

https://twitter.com/vlasovskikh/status/801720613312364544

There is a clear selection bias here, which is revealed in the first response (unless that was what you're pointing people towards). IDEs are a lot more common on Windows, which has the best adoption rate. The data from the two sources in that comment point towards a large majority of users still using 2.7, which agrees with my experience (which is in the scientific community). The number one reason being that there is no incentive. There is a lot of that attitude is common, "if it isn't broken, don't fix it". At this point we need to recognize that python2.7 isn't going to die anytime soon, unless there is a drastic change.

Re: Why I'm Making Python 2.8

#225

Post by godelski »

philipov wrote: post #155
coldtea wrote: post #143

Earlier quoted context omitted.

> Please, do not put obsolete software on life support. Regarding adoption, it's 3.0 that's obsolete, and 2.7 that's vibrant. Even for new code (they conveniently only count totally greenfield projects, but most new code is written in fact to work with established 2.x codebases under Python 2, not as a totally greenfield project).

Citation please.

I found these

https://semaphoreci.com/blog/2016/11/11/python-versions-used...

http://astrofrog.github.io/blog/2015/05/09/2015-survey-resul...

Re: Why I'm Making Python 2.8

#226

Post by paulddraper »

coldtea wrote: post #198
duckmysick wrote: post #160

Earlier quoted context omitted.

> it's mostly blackmail ("port or else you wont run on 3, and we'll stop the 2.x line"). Would you also call the RHEL life cycle a blackmail? I'm using version 5 now and the normal support ends in March 2017. My options now are "port or pay extra for extended life cycle or else my RHEL will be without security fixes". And like Python, major RHEL versions break backwards compatibility.

> Would you also call the RHEL life cycle a blackmail? The RHEL life cycle is based on real business needs (and a real business need to balance between newer releases/features and stable environments). Not on some decree from above that "you should use this new thing".

"The RHEL is based on...some decree from above"

Re: Why I'm Making Python 2.8

#227

Post by js8 »

coldtea wrote: post #193
js8 wrote: post #190

Earlier quoted context omitted.

> That's just what the lead project team declared. Not what the user base asked for or wants. You think they are doing it just for kicks? There are no issues with Python 2? They are also part of the user base, and they did it for a reason. > That's because people stopped using them organically. That's not the case with Python 2 -- Python 3 was declared "the new hotness" with a decree from above. Well, I for instance…

> You think they are doing it just for kicks? Yes. From a false sense of "we know better than you what's good for you". And also from not being connected to actual business and end user needs. > There are no issues with Python 2? That's irrelevant. There are issues with Python 3. Besides, the issues that Python 3 fixed over 2 are marginal at best and most could be retroffited to 2.x (as this 2.8 release proves). Noth…

> And also from not being connected to actual business and end user needs.

I am not really personally bothered by Python 3 being incompatible (with that one Jython exception that I already mentioned). But I would like to point out the comment https://news.ycombinator.com/item?id=13146127, I think you're the one who is wrong here.

> It's more likely that Python will suffer from people moving to other languages

Unlikely. Rails are probably going out of fashion. Javascript is a terrible language, which only saving grace is a decent support in browsers. I am not sure for what other reason, choosing a language today, I would choose Javascript over Python 3.

So people moving from Python 2 are most likely to end up with Python 3, I don't really see compelling alternative for them (unless they are going to something more functional like Clojure or Haskell or Scala, but that's entirely different discussion; for example I like Python a lot but I feel pure functional is where the future is, I find the imperative programming quite annoying these days, I would prefer Haskell, but frankly, I am not nearly as productive in it as I am in Python, because Python's focus on usability is very hard to match by any language).

On the other hand, I think Python 3 will actually gain in science and data analysis thanks to things like @ operator for matrix multiplication.

Re: Why I'm Making Python 2.8

#228

Post by paulddraper »

vosper wrote: post #185
susan_hall wrote: post #175

Earlier quoted context omitted.

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…

If I was your client I'd be pissed that you decided to rewrite my code into a legacy version of Python. Make no mistake: Python 3 is the future of Python. There will be no version 2.8 and there is no going back to 2.7. Also, I don't know what you mean by "Amazon only supports 2.7" because boto (the main client for Python) has supported Python 3 for 2 years now. Perhaps you mean Lambda?

He means Lambda.

Re: Why I'm Making Python 2.8

#229

Post by ianamartin »

guitarbill wrote: post #171
jzwinck wrote: post #133

Earlier quoted context omitted.

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

I say this as someone who uses the latest version of Python available in every new project or script.

Text encoding issues are absolute garbage in Python 3.x

I fucking hate the way that csv module works with text encodings.

As soon as I can figure out a reliable way to take latin-1 and save it as UTF-8 without breaking everything, I will try to shoehorn in a PR.

Right now, it's fucking awful. My ETL pipeline hates it, I hate it, my boss hates it, and my internal constituents hate it. Because it sucks.

A file I can read in one encoding and write as another should be readable with the encoding I wrote it in. That is not currently the case with the latest version of Python.

And it makes me hate the world.

Re: Why I'm Making Python 2.8

#230

Post by ianamartin »

wfunction wrote: post #69
xrisk wrote: post #63

Earlier quoted context omitted.

So you _hate_ Python 3 because of two changes in syntactic sugar? I would understand if you hated it because of the real breaking changes, but no... I think you just don't comprehend the multitude of problems that Python 3 fixes by handling strings correctly... Maybe you've never handled Unicode before.

> So you _hate_ Python 3 because of two changes in syntactic sugar? First of all, the tuple unpacking one is a HUGE readability AND maintainability issue; it's not just syntactic sugar. var[0][1][2] is not only far less readable than the unpacking notation, it doesn't even have the same semantics (doesn't enforce the structure of the tuple). That means Python 2.7 helped me catch more bugs . Think about that! Second,…

If your needs are for static analysis and type checking at compile-time, you are using the wrong language.

I'm a huge lover of Python, but I drop into C# when I need stuff like that. Or Go. Or Rust. Or something.

You're just making bad decisions here.

If you're looking to catch bugs in your code before you test or deploy it, don't use a dynamic language.

Python has never been and probably never will be a language with declarative types and the checking that allows.

Pick a different hammer if that's the nail you need to hit. Don't complain about the hammer you want to use not being a screwdriver.

Post reply on HN