←back to thread

2024 points randlet | 1 comments | | HN request time: 0.207s | source
Show context
bla2 ◴[] No.17515883[source]
> I don't ever want to have to fight so hard for a PEP and find that so many people despise my decisions.

Leading a large open source project must be terrible in this age of constant outrage :-(

replies(9): >>17515955 #>>17515972 #>>17516193 #>>17516427 #>>17516776 #>>17516884 #>>17517282 #>>17517716 #>>17517821 #
symmitchry ◴[] No.17515972[source]
I'm a little confused though, by his feelings here. Why did he feel the need to "fight so hard for a PEP" if it was so controversial, and everyone was outraged?

I do understand people's points about "the age of outrage" and "internet 2018" but still: the PEP wasn't generally accepted as being a fantastic improvement, so why did he feel the need to fight so hard for it?

replies(5): >>17516128 #>>17516129 #>>17516223 #>>17516774 #>>17519017 #
jnwatson ◴[] No.17516128[source]
It was controversial syntax, inline assignment-as-expression. There's always a tension between "keep it simple stupid" and "let's make it better", especially when a large user demographic of Python are non-professional-programmers.

Interestingly, C++ is going through the same process, with lots of great ideas being proposed, but the sum total of them being an even more complicated language (on top of what is probably the most complicated language already).

Python has been successful, IMHO, because Guido has made several brave, controversial calls. Python 3 breakage and async turned out to be prescient, fantastic decisions.

replies(6): >>17516204 #>>17516226 #>>17516681 #>>17517178 #>>17517212 #>>17533584 #
coldtea[dead post] ◴[] No.17516204[source]
>Python 3 breakage and async turned out to be prescient, fantastic decisions.

Async maybe. Python 3 breakage? Did you forgot the /s tag?

ben509 ◴[] No.17516612[source]
No, the bad decision was treating bytes and strings interchangeably in the first place. 99% of the hardest to fix breakage was due to that, and it was the right call to pay that price all at once.
replies(6): >>17516995 #>>17517386 #>>17517687 #>>17518069 #>>17520956 #>>17528411 #
jessaustin ◴[] No.17516995[source]
The API in 2 is not optimal, but they fixed it the wrong way. As you know, some operations make sense with bytes, and some make sense with character strings. The operations that make sense with character strings would also make sense with bytes when an encoding is specified. Therefore, there should just be a way of annotating bytes with a suggested encoding. Then byte-oriented packages (e.g. those that deal with data sent over an interface like a socket or pipe) could simply ignore the issue of encoding. Whole classes of errors would just disappear for many python coders. Other coders, who do care about encodings and non-ASCII characters, would still get those errors but that would be OK because they would know how to fix those errors.

So yes some breaking change was indicated, but the particular change that was made was the wrong one.

replies(4): >>17517441 #>>17517444 #>>17517465 #>>17522768 #
1. kqr ◴[] No.17522768[source]
Encodings are related to storage and transportation -- not business logic. You should not have to deal with encodings inside your application, so forcing programmers to deal with encodings at the point it matters, when text enters and exits the application, is thus sound.

If yoy truly don't care whether or not the text is decodable (which is sometimes the case), then don't read it as a string, read it as a byte array.

You can still have methods that are generic over byte arrays and text, since that is an orthogonal concern.