Well, yes, otherwise when I go to update from the source(s) then they don't match and I get even more duplicates.
And the filenames aren't "Broken" they're just not Python friendly, likely some other encoding like CP1252, but rather than play guess the encoding I want to just record the filename as stored on the disk in the database, and unzip the file, and do other horrible things to the file, but using the original name.
Fair enough. Looks like you're stuck with passing
bytes around then.
I would say those two categories address very different concerns.
Sure, but that's not nearly as fun or inflammatory. I don't think that Rust's "safety" is worth switching away from C (or C++) but Python is a proper "next step" above C. Whether that's actually worth anything or not is a different matter. I do think that it's a better first/beginner language though.
Ex: C++ and Rust can be used for kernel development but I can't see Python being used there at all (except for things like build scripts).
What percentage of programmers are kernel developers? The majority of programmers (especially Rust shills) aren't doing kernel/embedded, and those that are are probably using C (or maybe C++ without exceptions, etc.). Python is good enough for a lot of programs (a lot of heavy lifting libraries, e.g. numpy, are written in C, but the programmer doesn't interact with C directly so I'm counting that as Python). I used to write C++ before switching to C and most of the time "why would you do that? how can you even write anything in C? it doesn't even have my favourite high level language feature!" can be answered with either "I don't need it", "I don't want it", or "That's what Python is for".
:-)
It lacks the best feature of C++ (that Rust borrowed

), which is RAII.
RAII is one of the few things that I miss from C++, along with operator overloading and proper custom types. I've considered "C with classes" before, but I haven't written a serious program in it yet. Python does have
with, and there is a
__del__ magic method, which is basically temu RAII? It's been good enough so far, though.
Python is only a step up from shell. Making any decently sized program in it is pain. [...] Unless you actually treat is as quasi shell, only gluing foreign libraries.
Portable Shell++ ? Works on Windows and Linux (and without any
#ifdef'ing!) I'm tempted to say "skill issue" on this one, tbh. Writing a large program in any language adds complexity that needs to be managed.
Also Python performance is actually so horrible that it starts to matter again.
If you're waiting 300ms on I/O, does it really matter if the code takes 1ms or 20ms to run? One of the best features of Python is that you can just (re-)write a module in C and there's no gay "ffi" annotations that you have to scatter everywhere. You can eventually re-write the "glue" in C too. Second-best language is a gateway drug to best language. Writing directly in C is probably better, but sometimes a "rapid prototyping" stage is useful and Python is better for that.
Is it really that good for learning programming though?
It depends on if you want to learn how the computer works, or how to make the computer do stuff. Most people don't care how the computer works, or how to do things properly, or why JavaScript is an ungodly abomination, etc.
Python gets rid of a lot of noise, it doesn't get in the way (most of the time), and it's easy to start with a small subset and gradually add concepts. It isn't the worst language to learn with.