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

The Case Against Python 3

learnpythonthehardway.org

Post reply on HN
Print view View original

181–190 of 281 posts

Re: The Case Against Python 3

#181

Post by kbenson »

chongli wrote: post #153
kbenson wrote: post #94

Earlier quoted context omitted.

A language must change, or it will be left behind, and become an esoteric toy. Even C has to deal with this. The only reason C is still popular is because of it's grandfathered status in so much of our infrastructure, and in many of the popular OS choices. A language that changes will alienate people, and lose people. Perl saw this. Python is seeing this. The way to guard against this is to keep backwards compatibili…

Even C has to deal with this. But is there any C11 compiler out there that will refuse to compile C99?

I used C as an example of what happens when you don't change, not what happens when you do. C is used decades later with little change because of momentum and history, not because it's the pinnacle of computer languages.

C is not a good language. It was a good language, but that was a few decades ago. We've progressed past the point where C's shortcomings are excused by there not being alternatives that address those shortcomings while offering comparable features. At this point, we're just finally edging past of the local maxima created by C's exceptional popularity and the knock-on effects of that popularity, such as most operating systems (and all popular open source ones) being written in C.

Re: The Case Against Python 3

#182

Post by obeleh »

This must be a serious attempt to troll the interwebs. https://meta.wikimedia.org/wiki/Cunningham's_Law "the best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer."

This REEKS of wrong answers. Turing completeness? Py3 in Py2? The argument that bytes are to confusing?

Re: The Case Against Python 3

#184

Post by kpil »

The "unicode" string changes in python 3 is enough for me to avoid it, as they somehow managed to go from broken to brain dead.

Mandatory utf-8 strings would had been a reasonably nice solution I think.

Re: The Case Against Python 3

#185

Post by kqr »

joatmon-snoo wrote: post #93
lisper wrote: post #67

> The strings in Python 3 are very difficult to use for beginners. In an attempt to make their strings more "international" they turned them into difficult to use types with poor error messages. Every time you attempt to deal with characters in your programs you'll have to understand the difference between byte sequences and Unicode strings. The author has this exactly backwards. It is Python2 that makes the weird di…

As someone who's used Python 2 for the past half decade and started using Python 3 only recently, 100% with you on this. The first time I was working on a project which required me to be able to work with characters beyond ASCII, I was so confused. To this date, I'm still not sure if I can actually explain what str.encode and str.decode do in Python 2. Admittedly I've never used Python 3 for a project where I had to…

> his point about the concatenation of unicode and bytearrays certainly seems a valid point

This is one of those subjects where I feel like being a non-English programmer has given me surprisingly valuable experience.

The operation of concatenating a text value (string) and binary data (byte array) simply does not make sense, for two reasons. What do you expect the result to be?

1. Binary data with the text appended. Then you need to specify which encoding you want the text to have. Once you do (a.encode('utf-8')), all will be fine. You could argue that a conversion to utf-8 should be implicit since that's almost always the correct choice, but you'd be surprised how fast you run into trouble with other systems.

2. Text with the binary data appended after interpreting it as text. Again, which encoding? You'll get very confusing and terrible results if you do not specify this. If you specify this (b.decode('utf-8')) everything will be fine.

The only other alternative I accept is a type error. I'm guessing zed would be even angrier if that was the case. I'm not quite sure what Python 3 does, but at least it somewhat communicates that whatever interpretation it does is internal and arbitrary. The Python 2 result is ridiculous.

Re: The Case Against Python 3

#186

Post by blub »

awinter-py wrote: post #34

The argument is bad but the headline has a point: the value of a language is the quality of its libraries and the community that maintains it. Python 3 seems like a mistake; it fractured the community and sent people away. (to golang, to scala, probably even to ruby). If I were a library maintainer on py2 I would have felt betrayed by py3. Suddenly print is a function? 'yield from' won't be available on the py2 branc…

Errr... what?! C++ is a positive example of language change, because it keeps backwards compatibility, unlike Python where we're still having discussions about 2vs3 after 8 years.

Nobody is having discussions about C++14 vs C++98, the latter is better period. A C++14 compiler will compile C++98 code just fine in most cases. If it doesn't you get a compile time error.

People are complaining about the opposite, that C++ is keeping compatibility for too long and that it has too many features. Both strategies have their pros and cons, but breaking seems to have more negative effects.

C has done a great job of supporting buffer overflows on lots of platforms and injecting safety errors in all software that uses those libraries.

Re: The Case Against Python 3

#188

Post by flukus »

kbenson wrote: post #181
chongli wrote: post #153

Earlier quoted context omitted.

Even C has to deal with this. But is there any C11 compiler out there that will refuse to compile C99?

I used C as an example of what happens when you don't change, not what happens when you do. C is used decades later with little change because of momentum and history, not because it's the pinnacle of computer languages. C is not a good language. It was a good language, but that was a few decades ago. We've progressed past the point where C's shortcomings are excused by there not being alternatives that address those…

What's replacing C? I can see languages like go/rust/crystal replacing C++ for application development, but what's producing stable binaries that other languages can consume in the same way the do C ones?

Re: The Case Against Python 3

#189

Post by AstralStorm »

hartator wrote: post #134

I hope we can just call Python 2.8 -> Python 4 and do a bridge to import the good things about Python 3. Agreeing or not agreeing with the author points is irrelevant, Python is slowly and unfortunately dying because of this schism.

Never. Python 4 would be another breaking change that is not a step back. Not over BDFL's dead body will this happen.

Re: The Case Against Python 3

#190

Post by kqr »

banachtarski wrote: post #84
kough wrote: post #68

Earlier quoted context omitted.

Javascript is a colloquial name for what is formally known as ECMAScript. There isn't a language named JavaScript :)

I would argue the technicality you pointed out is a lot more minor than the OPs. The OP was basically talking about the JVM as if it was a language. *edit typo

Well, there is a Jim language, it's just not something you'd want to write by hand...
Post reply on HN