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

Python 3: Ten years later

archive.fosdem.org

Post reply on HN
Print view View original

81–90 of 93 posts

Re: Python 3: Ten years later

#81

Post by kmarc »

Rotareti wrote: post #64
kmarc wrote: post #30

Just one word: typing [1]. Makes life a lot easier. [1]: https://docs.python.org/3/library/typing.html

Two words: typing, mypy [1] The editor support that I get from typing/mypy is fantastic! It feels like writing in a statically typed language. To me this is by far the most important feature of Python3. It's a godsend for larger/complicated code bases. [1]: https://github.com/python/mypy

Yes, you are right. I'm also using mypy along with pylint, yapf and isort. Helps keeping my python codes clean

Re: Python 3: Ten years later

#82

Post by slavik81 »

ubernostrum wrote: post #77
slavik81 wrote: post #53

Earlier quoted context omitted.

I saved this page from the English Wikipedia as input.txt: https://en.wikipedia.org/wiki/Shinz%C5%8D_Abe C:\Users\local\tmp>python --version Python 3.7.1 C:\Users\local\tmp>python foo.py Diet Parliament Traceback (most recent call last): File "foo.py", line 7, in text = f.read() File "C:\Users\local\AppData\Local\Programs\Python\Python37-32\lib\encodings\ cp1252.py", line 23, in decode return codecs.charmap_decode(in…

The way I usually put it is that Python 3 shifted its priorities. Previously, if you were a UNIX-y scripter writing UNIX-y scripts on your UNIX-y OS, the fact that Python just kind of pretended encoding issues would never exist was a help to you. It adopted the same "everything is ASCII, or at most UTF-8 in the ASCII range, and if it isn't I'll break in cryptic ways" approach as most other UNIX-y scripting things. If…

So, write the program correctly. Show me.

> Python 3 decided to make the UNIX-y scripters actually learn what a horrid mess UNIX is with respect to locales and encodings and filesystem paths

Show me how much Python 3 improves this. To expand on the program before, make it a directory named 'input' full of files, and a directory named 'output' to put the processed files in. Print each file name as the corresponding file is processed to indicate progress.

I would be applauding Python if it did make the difficulties with this exercise obvious, but it absolutely does not. The file system APIs return strings, but the strings they return may not be valid Unicode. PEP 383 turned the Python 3 str type into a bag of bytes.

Python tries to sweep encodings under the rug. It makes the encoding a default value all over the place and hides conversions everywhere.

I 100% agree that developers need to think about encodings and handle them in their programs. That's exactly why I hate string handling in Python 3: because rather than making you handle the corner cases, it pretends they don't exist, until they're found one by one by your users.

Python 3 encourages developers to write broken string handling code.

Re: Python 3: Ten years later

#83

Post by ravenstine »

bakery2k wrote: post #25

No, IMO. Don't get me wrong, Python 3 is a better language than Python 2. I just don't think it's that much better that it was worth breaking backwards compatibility and stalling the language for several years. Python 3 did enough to break everyone's existing code, but nowhere near enough to make that worthwhile. It's common for other language communities to consider the Python 2/3 transition as an example of "what n…

How hard is it to simply keep one's code up to date? I'm pretty sure there weren't any radically different paradigms introduced in Python 3.

Somehow the world of JavaScript has been able to quickly adapt to a rapidly changing language and the community is hardly fractured along the lines of language. Adopting new language features and browser APIs is just a matter of fact. What's different about Python?

Re: Python 3: Ten years later

#84

Post by ubernostrum »

slavik81 wrote: post #82
ubernostrum wrote: post #77

Earlier quoted context omitted.

The way I usually put it is that Python 3 shifted its priorities. Previously, if you were a UNIX-y scripter writing UNIX-y scripts on your UNIX-y OS, the fact that Python just kind of pretended encoding issues would never exist was a help to you. It adopted the same "everything is ASCII, or at most UTF-8 in the ASCII range, and if it isn't I'll break in cryptic ways" approach as most other UNIX-y scripting things. If…

So, write the program correctly. Show me. > Python 3 decided to make the UNIX-y scripters actually learn what a horrid mess UNIX is with respect to locales and encodings and filesystem paths Show me how much Python 3 improves this. To expand on the program before, make it a directory named 'input' full of files, and a directory named 'output' to put the processed files in. Print each file name as the corresponding fi…

So, write the program correctly. Show me.

You just want to fight someone because you're angry, and I don't do that. No matter what someone writes you'll find a way to argue into it being wrong and then prance around declaring "victory".

(I'd also bet that you probably couldn't do it if I were the one who got to set the evaluation criteria, and you also couldn't pass other "challenges" like writing proper HTTP handling -- the person who gets to grade the challenge always "wins", which is why you want to be the person who grades the challenge)

PEP 383 turned the Python 3 str type into a bag of bytes

PEP 383 provided a way to read certain things -- primarily filesystem paths which can be basically anything -- using an escape mechanism to replace non-decodable bytes with surrogates when decoding to string, which in turn allow losslessly transforming back to the original bag of bytes.

Which is necessary, because there are real filesystems out there that really have paths and names that can never validly decode from any known text encoding. It doesn't turn strings into "bags of bytes"; the resulting str still is an iterable of actual valid Unicode code points.

Python tries to sweep encodings under the rug.

As the saying goes, you can't reason someone out of a position they didn't reason their way into, so I won't try here.

Python 3 encourages developers to write broken string handling code.

Python 3 no longer tries to cover for the random gibberish that's legal to put in filesystem paths, and makes the developer handle it. Are there lots of developers out there who don't realize that filesystem paths can legally contain undecodable garbage? Sure. That's not Python's problem to solve, though; it gives you the surrogateescape handler, and the fsencode helper, and keeps working on things like PEP 538 and PEP 540 to try to give you tools to work around it. But Python can't magically fix the mess that is UNIX locales and bag-of-bytes paths (nothing can, short of burning UNIX down and starting over), and doesn't try to do it for you.

Re: Python 3: Ten years later

#85

Post by slavik81 »

ubernostrum wrote: post #84
slavik81 wrote: post #82

Earlier quoted context omitted.

So, write the program correctly. Show me. > Python 3 decided to make the UNIX-y scripters actually learn what a horrid mess UNIX is with respect to locales and encodings and filesystem paths Show me how much Python 3 improves this. To expand on the program before, make it a directory named 'input' full of files, and a directory named 'output' to put the processed files in. Print each file name as the corresponding fi…

So, write the program correctly. Show me. You just want to fight someone because you're angry, and I don't do that. No matter what someone writes you'll find a way to argue into it being wrong and then prance around declaring "victory". (I'd also bet that you probably couldn't do it if I were the one who got to set the evaluation criteria, and you also couldn't pass other "challenges" like writing proper HTTP handlin…

You're right that I'm frustrated. I'm not even upset at anyone in this thead, but from previous discussions. I appologise for carrying that baggage here. Having my morality questioned when I legitimately want to make programs work correctly for foreign languages has left me... emotional on this subject.

Unix has its own problems, but the program avian wrote works correctly on Linux. Most encoding issues I encountered when working with Python 3 were on Windows.

PEP 383 was making the best of a bad situation without breaking the API again. The real mistake was having the functions return strings in 3.0. The operating system APIs should have returned path objects that require an explicit conversion to string with an explicit error handling mechanism.

Python gives you all the tools you need to do this right, but they're easy to unknowingly use in ways that break on corner cases. A well-defined API should guide you towards the correct solution and should make pitfalls obvious.

In any case, I should probably give it a rest. I work hard to make sure my programs do this stuff right, and I suppose that's all I can really do.

Re: Python 3: Ten years later

#86

Post by c22 »

Al-Khwarizmi wrote: post #27
iagooar wrote: post #18

As an outsider who only uses Python when I need a specific tool that's only available through pip: it's still one of my biggest nightmares. Every single time I need to install something with pip on MacOS there is this hour-long struggle with figuring out how to get the correct version of Python (2.7 vs 3) working with the correct version of pip working with the correct version of the library itself. I don't know, I g…

I use Ubuntu and it's the exact same thing for me, so I don't think it's MacOS-specific. To be honest, the whole versioning quagmire is the main reason why I don't use Python as one of my main languages, but just as an outsider like you. I like the language but I hate wasting my time with that kind of thing. Say what you will about Java, but you can just slap a jar file into a folder and it will work with the latest…

On my Debian box I notice I have pip2.7 and python2.7, but also pip3.4, python3.4, pip3.6, python3.6, etc... If I want to install something for python2.7 I just use pip2.7. It looks like on this system python and pip are just symlinks to python2.7 and pip2.7 while python3 and pip3 link to python3.8 and pip3.8

It never seemed that hard to keep track of the different versions.

Re: Python 3: Ten years later

#87

Post by MR4D »

Python 3 is the open source equivalent of Vista - too much potential, but too much time to realize it, and the world doesn’t slow down in the meantime.

I love python. For me, it’s damn near perfect in many ways. But it’s looking more and more like Perl 6 than what it should have been.

The sooner we get to Python 4 (whatever that ends up being), the better, as we need to move past the v2 or v3 question for developers and users.

Re: Python 3: Ten years later

#88

Post by h1d »

t0mbstone wrote: post #68
tarboreus wrote: post #54

Earlier quoted context omitted.

i highly recommend pyenv to resolve this issue on Mac OS and Linux: https://github.com/pyenv/pyenv

Yep! Pyenv for Python, rbenv for Ruby, NVM for node.

My experience using nvm has been quite annoying.

What you could do with simple npm command now doesn't work unless you give additional command lines when it comes to cron and other non interactive environments like process monitoring to restart the process.

Re: Python 3: Ten years later

#89

Post by h1d »

ravenstine wrote: post #83
bakery2k wrote: post #25

No, IMO. Don't get me wrong, Python 3 is a better language than Python 2. I just don't think it's that much better that it was worth breaking backwards compatibility and stalling the language for several years. Python 3 did enough to break everyone's existing code, but nowhere near enough to make that worthwhile. It's common for other language communities to consider the Python 2/3 transition as an example of "what n…

How hard is it to simply keep one's code up to date? I'm pretty sure there weren't any radically different paradigms introduced in Python 3. Somehow the world of JavaScript has been able to quickly adapt to a rapidly changing language and the community is hardly fractured along the lines of language. Adopting new language features and browser APIs is just a matter of fact. What's different about Python?

JavaScript has been stuck with an ancient version because of browser adoption like IE6.

There's a good reason people wanted to migrate to newer JS and I never heard people say ES6 got something wrong over ES5.

Re: Python 3: Ten years later

#90

Post by imtringued »

slavik81 wrote: post #53
avian wrote: post #52

Earlier quoted context omitted.

Ok, I'll bite. This is the most straightforward way I can think of to implement the program you described. I think this is more or less what someone would come up with after glancing at the Python tutorial: https://gist.github.com/avian2/e3968bf933212ee561410b15495e6... What is wrong with it? It works as expected with non-ASCII characters in both command-line arguments and in input.txt (Python 3.5.3 on Linux, LANG=en…

I saved this page from the English Wikipedia as input.txt: https://en.wikipedia.org/wiki/Shinz%C5%8D_Abe C:\Users\local\tmp>python --version Python 3.7.1 C:\Users\local\tmp>python foo.py Diet Parliament Traceback (most recent call last): File "foo.py", line 7, in text = f.read() File "C:\Users\local\AppData\Local\Programs\Python\Python37-32\lib\encodings\ cp1252.py", line 23, in decode return codecs.charmap_decode(in…

Well as you can see the problem is that open without encoding arguments uses the system default settings (in this case cp1252) which is always a terrible idea regardless of how a language represents strings internally.

Honestly it surprises me how simple and easy it is to understand this trace and I'd agree with the statement that this is a good user experience.

Post reply on HN