&gt; That&#x27;s how C ended up as the security nightmare that it is.<p>And that&#x27;s how I ended up completely wasted after a friend had to throw a party after a GNU version of a common unix tool was able to accept his first name as valid parameters.<p>And no, C&#x27;s problem are <i>not</i> based on encoding issues. Those are not even a first-class symptom.<p>&gt; Python is not that kind of language<p>Maybe. I don&#x27;t care much, even though I do speak Python fluently. Though, I <i>do care</i> about minimal functional units whose documentation I can grasp in minutes, not hours.<p>&gt; [Python] will go to some pains to help you not make mistakes.<p>This is not specific to python, this is specific to [language] developers. If all you do is text processing, you will think in characters and their encoding. I don&#x27;t. A lot of programmers don&#x27;t - because they deal with real world data that is almost never most efficiently encoded in text.<p>To reiterate: We are all dealing with bit-streams. Semantics of those are specific to their context. If your context is &quot;human readable text&quot; - deal with it. But please don&#x27;t make me jump through hoops if I actually just want to deal with bit-streams. If you need magic to make your specific use-case easier, wrap the basic ops in a library and use it.<p>Last but not least: This all is completely off-topic when the question is about &quot;why python3&quot; - it&#x27;s great for your use-case, but from an abstract point of view, python3 was just the rational continuation of python2, cleaning up a lot of inherited debt. Though it might fit your world-view, it&#x27;s not necessarily what it was about.