Numpy: Plan for dropping Python 2.7 support

Re:Numpy: Plan for dropping Python 2.7 support by jimmaswell on Wednesday November 15, 2017 @07:48PM (#15709409)

When I use python as a scripting language for small tasks I want something concise and convenient that just works. Python 3 is a downgrade in all those areas. I want to just some input into a string, do some operations on it, and print the result. Now I have to make extra special sure to convert the string between binary or utf8 as appropriate, catch encoding exceptions, not try to print anything that might have binary in it, and even the simple print statement was caught in this impractical mess that feels like it was designed by an out of touch academic committee comprised of people who'd never written real code in their lives deciding that string should actually mean only printable characters within a defined encoding and that statements are considered harmful. I can't wait for return to be a function too in python 4.

[ Parent | on HN ]

Re:Numpy: Plan for dropping Python 2.7 support by zbentley on Thursday November 16, 2017 @02:13AM (#15710753)

I suggest reading the eev.ee article others are linking in these comments. Or Joel Spolsky's "Back to Basics" article. Both do a pretty good job of highlighting some of the complexity in this area, and why things sometimes seem like they're being made harder.

Put most concisely, it's something like "making the most common use case as easy as possible can make slightly less common use cases wrong, dangerous and hard".

It's not an out of touch academic committee making these changes out of ignorance or spite. It's people who have to support more use cases than yours. Even if yours is the most common, that doesn't mean that the rest (internationalization, binary data transfer) are distant, rare outliers, or that the frequency of non-traditionally-"simple" ascii text handling applications isn't changing.

[ Parent | on HN ]

Re:Numpy: Plan for dropping Python 2.7 support by int_19h on Wednesday November 15, 2017 @10:21PM (#15710048)

You don't need to do any of that. If you use `input()`, you get a string - all conversions are done for you. If you're reading from a file (or from stdin, treating it as a file object), again, in text mode you just get strings. Same thing for printing - if you print strings, they will get converted to the encoding appropriate for the target terminal.

So, what is it exactly that you're trying to do?

[ Parent | on HN ]

Re:Numpy: Plan for dropping Python 2.7 support by jimmaswell on Wednesday November 15, 2017 @10:23PM (#15710056)

IRC logs with IRC control code characters in them don't work nicely with python 3 text strings, for example.

[ Parent | on HN ]

Re:Numpy: Plan for dropping Python 2.7 support by int_19h on Saturday November 18, 2017 @10:28AM (#15729304)

Why not? There's no restriction on what kinds of characters can appear inside a Python Unicode string.

Or do you mean that the text in the log is UTF-8, but the log itself as a whole is not, because those control characters are mixed into it in (effectively) a different encoding? Then the log isn't a single string, and shouldn't be treated as such.

[ Parent | on HN ]

Re:Numpy: Plan for dropping Python 2.7 support by masklinn on Thursday November 16, 2017 @04:17AM (#15711271)

> When I use python as a scripting language for small tasks I want something concise and convenient that just works. Python 3 is a downgrade in all those areas.

Funny, I found the exact opposite, and despite $dayjob being LCD(2, 3) and the default Python on my system being 2, I've been writing all my small scripts in 3.6.

[ Parent | on HN ]

Re:Numpy: Plan for dropping Python 2.7 support by speedplane on Thursday November 16, 2017 @04:23AM (#15711301)

Python 3 has plenty of objectively good stuff, and some that is definitely more subjective. I have my opinions about the changes, but I don't get outraged over them.

The real crime of Python 3, is not the changes, but the compatibility break. Hundreds of thousands of engineer-hours wasted on porting, worrying about compatibility, and supporting unsupported libraries or two environments at once. In the meantime, the language does not meaningfully advance, and thousands of projects are slowed down. It's such a huge effort for a gain that is not worth it.

[ Parent | on HN ]