Live data from Hacker News

Why I'm Making Python 2.8

naftaliharris.com

231–240 of 392 posts

Re: Why I'm Making Python 2.8

#231
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.

Re: Why I'm Making Python 2.8

#232
post #187

Earlier quoted context omitted.

> the text model of Python 2 is a giant mess and makes it very hard to correctly deal with non-ascii text for any non-trivial software There are counter-arguments to this. Armin Ronacher, author of (among other software) the excellent Flask web framework, thinks that Python 2's system of codecs and byte streams is better in practice [1][2]. Reasons include: You can do byte -> byte conversions with codecs that are no…

Armin has backed off of this stance since then. And for good reason. As someone who works with Python text processing extensively, I can tell you that the Python 2.7 text model is broken and dangerous, due to the silent bytes-unicode coercion and misguided use of ascii instead of UTF-8 as the default text encoding. Many people don't realize this and will argue that it's not broken, because they have never fed non-asc…

Yeah, but if you are dealing only with a subset of the English Language in the U.S., and your API endpoint that you are scraping wants to serve to all peoples in all locales in all situations, you are fucked if you want to use Python3 and its csv module.

You genuinely are better off using Python 2.7.x and its naive approach to text.

Re: Why I'm Making Python 2.8

#233

Earlier quoted context omitted.

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…

While the claim of selection bias in JetBrains' survey may be argued, it is still a valid data source, which is what the gp was asking for.

Also, your anecdotal data is arguably biased as well.

My take is that many sources, including the ones linked to in the tweet's replies point to solid growth in Python 3 adoption. Python3 might not have overtaken Python 2 overall, but it's very far from being "dead".

Re: Why I'm Making Python 2.8

#235
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…

> What a load of bollocks. [Snip] For old projects, either you're in a situation where you can spend time porting your code to Python 3

The majority of Python code is old projects, just like every other established language. This might change in the future as I now see people starting new projects in Python 3, but if your company is older than 5 years old, then there is a good chance that you started with Python 2 simply because at the time of creating your codebase a whole lot of libraries weren't ported to Python 3.

Re: Why I'm Making Python 2.8

#236

Earlier quoted context omitted.

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…

While the claim of selection bias in JetBrains' survey may be argued, it is still a valid data source, which is what the gp was asking for. Also, your anecdotal data is arguably biased as well. My take is that many sources, including the ones linked to in the tweet's replies point to solid growth in Python 3 adoption. Python3 might not have overtaken Python 2 overall, but it's very far from being "dead".

>My take is that many sources, including the ones linked to in the tweet's replies point to solid growth in Python 3 adoption. Python3 might not have overtaken Python 2 overall, but it's very far from being "dead".

I wasn't making the point that Python 2 is dead, in fact quite the opposite. I'm saying that with this many users the adoption rate is too slow. There is no real reason for people to switch. Until there is that incentive Python 2 will not die.

Re: Why I'm Making Python 2.8

#237
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.

There is nothing bad in making a newer version of an older language. But I agree they must use a more distinctive name.

Re: Why I'm Making Python 2.8

#238

Earlier quoted context omitted.

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

There are numerous metrics out there showing that Python 2.7 is far more ubiquitous than 3.x

Here is one recent one: http://www.randalolson.com/2016/09/03/python-2-7-still-reign...

If you have counter statistics showing that Python 3.x is more popular than 2.7 I would very much like to see them.

Re: Why I'm Making Python 2.8

#239
So when you see a project written in Python 2.8, you'll know that it contains lots of legacy code under active development by developers who are gung-ho about fancy language features, but that this team hasn't had the time/resources/gumption to do a code overhaul anytime in the past six years.

And also that you yourself, and any users of your own project, will need to run it with this guy's own homebrewed version of Python in order to know it will behave correctly.

Useful?

Re: Why I'm Making Python 2.8

#240

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…

Could you tell us which libraries you want don't support 3.x? Genuinely curious as i thought nearly all of the main ones were ported now

At this point, if a library I wanted to use didn't support 3.X, I would take that as a giant red flag not to use said library.
Post reply on HN