4 ms·
Python was a disaster. I still miss print statements and encoding-agnostic strings. Good on Go for doing the right thing.
by jimmaswell 3y ago
Python was a disaster. I still miss print statements and encoding-agnostic strings. Good on Go for doing the right thing.
- hk__2 3y agoPrint statements were a mistake. If you forbid breaking changes, you have no way to fix past mistakes in the language design. There’s noting inherently "right" in refusing to do breaking changes.
- jimmaswell 3y agoRemoving the print statement was the mistake to me. It violated Python's own stated principle of practicality over purity.
- rowanseymour 3y agoHaving two ways to do the same thing is the mistake, and print() was always more consistent with other built in functions are invoked.
- masklinn 3y agoThere was nothing practical about the print statement. The print function is easier to use, meshes a lot better with the langage, and can actually be extended without C++ style syntactic nonsense. The print function is one of the best things to come out of p3.
- dcow 3y agoI think if you'd ask any Python programmer today, they'd say Python is very much healthy and the community has successfully transitioned.
- jimmaswell 3y agoPython was my first language and I still use it sometimes. Still run into 2 vs 3 issues often.
- mrweasel 3y ago> encoding-agnostic strings Do you mean byte strings vs. strings in Python 3 or did you actually like string handling in Python 2, because that basically "Tell me that you only allow ASCII without telling me that you only all ASCII". I can see the issue with byte strings in Python3, it's annoying that you have to think about both strings and byte strings, but for dealing with actual text having everything just be unicode was reason enough to upgrade from 2 to 3. We deleted so much code dedicated to dealing with encoding during our switch to Python 3, everything just became better.
- jimmaswell 3y agoI had an IRC markov-like bot in Python. It used to be so simple in Python 2: - the bytes come in from the IRC server - they go in a string in the log, I can print this log to the console even if it has some IRC control codes (there will be a garbage character here or there but that's OK) - if I want to make a bold/color/etc I can just throw \xwhatever in the string. if a word from the log had bold in it and it's repeated back it will also have the bold in it. Then I reluctantly ported it to Python 3 and it was awful. Python now had to micromanage every single string to ensure I don't have any "naughty" bytes in it. Conversions to/from byte/string everywhere. Massive headache every time I wanted to read or write IRC encoded strings to a txt file or print them to the console or anything. In Python 2 the encoding only lived outside the program, in my terminal, text editor, and IRC clients. Bytes went in, bytes went out, and everyone was happy. Python 3 decided it needed to know exactly what was going on every step of the way and didn't trust me anymore, forcing me to do an elaborate song and dance to get anything done. I prefer my tools to have as little an opinion as possible. Let me open the door while I'm driving, let me run my web browser as root, and let me print \xDE\xAD\xBE\xEF to the console.
- mrweasel 3y ago> Python now had to micromanage every single string to ensure I don't have any "naughty" bytes in it. Oh that is annoying, our use case just fitted better into how Python 3 works. We went the opposite way. We micromanaged strings all over the place to ensure that encodings would always be correct. We needed unicode but also connected to Windows systems, which uses their own weird codepage system. Encoding and decoding was everywhere along with encoding detection. Python 3 made all that go away.