31–40 of 93 posts
Earlier quoted context omitted.
Why? I teach Python and c++ to A level students. They pick up the basics in a few weeks. C++ is pretty easy. We push our students through the c++ institute exam with few issues. Choose the right tool for the job. If you need speed, choose c
C++ is pretty easy!? Wow, that's an opinion you often don't hear. :-)
Python 3 is worth it just for Unicode handling. As someone using a language that is uses non-ASCII characters, thank you if you're using Python 3 and made your software more internationally compatible.
...or you could just use the unicode type in Python 2; like: all of my Python 2 software handled languages in other character sets correctly (and yes: this was stress tested often as I have had many many users from China and the Middle East). There was absolutely nothing wrong with Python 2 and Unicode, and if anything Python 3 just made a bunch of stuff impossible to do correctly (in particular encodings for filenam…
It’s not that Python 2 couldn’t do it, but the corner cases and error handling was a pain. Trying to guess encoding at runtime was pretty error prone, with Python 3 it just works.
Python 3 was a rocky transision, but I never understood the negativity and I’ll be happy to see Python 2 die, so our system can go back to having just one Python interpretter.
Earlier quoted context omitted.
You're suggesting the parent is lying about having used Python 2 and/or having felt that way?
It's completely impossible to have used Python 2 and not having felt miserable under a pile of UnicodeDecodeErrors.
There are still idiots on Github using Python 2 for new projects. These are usually academics who don't actually share any love for technology. Their code will never be used by anyone.
Earlier quoted context omitted.
...or you could just use the unicode type in Python 2; like: all of my Python 2 software handled languages in other character sets correctly (and yes: this was stress tested often as I have had many many users from China and the Middle East). There was absolutely nothing wrong with Python 2 and Unicode, and if anything Python 3 just made a bunch of stuff impossible to do correctly (in particular encodings for filenam…
We where able to delete so much code when we switched to Python 3. When you integrate with especially Windows system converting unknown text was tricky at best. It’s not that Python 2 couldn’t do it, but the corner cases and error handling was a pain. Trying to guess encoding at runtime was pretty error prone, with Python 3 it just works. Python 3 was a rocky transision, but I never understood the negativity and I’ll…
> Trying to guess encoding at runtime was pretty error prone, with Python 3 it just works.
You should not guess on 2.x either. On the other hand in 3.x the interpreter sometimes guesses the encoding for you when working with OS data on unix and that has lead to some absurd bugs when it falls into that surrogate handling fallback code: http://click.palletsprojects.com/en/7.x/python3/#python-3-su...
There are still idiots on Github using Python 2 for new projects. These are usually academics who don't actually share any love for technology. Their code will never be used by anyone.
There has been a pledge by the largest group of Python developers not to mess around with Python 2. So if you want your code to be able to just run forever without any concern for all the new and exciting language ideas being loaded into Python 3 then Python 2 is the logical choice.
I wonder, once 2.7 is EOL in a years time, whether the language developers will consider a "3.x LTS" release?
Earlier quoted context omitted.
...or you could just use the unicode type in Python 2; like: all of my Python 2 software handled languages in other character sets correctly (and yes: this was stress tested often as I have had many many users from China and the Middle East). There was absolutely nothing wrong with Python 2 and Unicode, and if anything Python 3 just made a bunch of stuff impossible to do correctly (in particular encodings for filenam…
Except doing the right thing by default is important, and the reality is that Python 3 code is way more likely to handle Unicode correctly, which is what we want. People constantly complain, but honestly changes like Python 3 have to happen - the alternative is just another completely new language taking over instead.
Write a Python 3 program that takes two arguments, reads a text file named "input.txt", replaces all instances of the first argument in the text with the second argument, and writes the result to "output.txt". For extra credit, add an option to print to stdout.
My bet is very few people would write that program correctly.
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 think Python 3 primarily showed that breaking backwards incompatibility across an entire ecosystem is worse than one could have predicted. Even today Python 2 is far from dead. On the other hand the core development team "outsourced" many of the issues that people actually want to have solved to the community like packaging and distribution. Python's biggest downfall is a highly academic approach with slow release…
I’m not sure what you mean. Are you suggesting that Python use UTF-8 encoded strings internally instead of decoded Unicode codepoints like it does currently?
I’ve worked on Perl that uses that approach and it’s an absolute nightmare. All string operations suddenly must be aware of details of UTF encoding, which complicates even simple things immensely. You get hard-to-find bugs when some code somewhere introduces invalid UTF to a string. The only real benefit you get is slightly smaller memory footprint when dealing mostly with English text.
I much prefer Python’s decode-process-encode approach.