whm1974 wrote:just brew it! wrote:Not quite old enough to be your dad. But as the forum admin I feel like I am sometimes...
Depend on how old you were when you started having children. One of my friends back in high school 11 y/o brother got some high school girl pregnant.
Talk about starting young...
Well this thread has certainly taken a weird turn. While I did start a family fairly young, I wasn't
that young. So while I'm old enough to be your parent technically/biologically, it would be... *ahem*... "very strange".
FlamingSpaceJunk wrote:Vhalidictes wrote:Probably a bigger concern is getting through multiple college programming classes (75% of the bachelor curriculum at least) without ever running into or reading about the FSTREAM class is probably an issue all of its own. I mean, seriously, how?!
Redirecting stdout and stderr in the shell perhaps? There is a lot of stuff that isn't covered in college.
College courses can indeed be very light on "how to actually apply this in the real world" type topics. On the one hand, that's a problem if you're trying to best prepare people to enter the job market upon graduation. On the other hand, you really do want to teach general principles instead of specific details, so that graduates have a context within which to learn as technology changes. When I was in college, UNIX was still relatively new; teaching specific details of the UNIX ecosystem would've been a bit of a gamble, since there was no guarantee that UNIX would catch on.
FlamingSpaceJunk wrote:Yep, all those things.
Staying within Python makes things much easier, and things get clunky when going outside the ecosystem.
Yeah, it's a bit of a "walled garden" approach, but the garden is really huge, and there's that dark corner at the far end where you can crawl through the bushes growing across the gap in the wall, and write Python-callable modules in C/C++ if absolutely necessary.
FlamingSpaceJunk wrote:I've come to terms with Python being an old school Unix program that favors forking over multi-threading. It makes sense for it's mission of simplicity, and the easiest way to not deal with locks and race conditions is to fork a process and make it communicate using IPC.
Yup. The GIL (Global Interpreter Lock) issue has kind of forced that mentality on the Python community. A few years back Google had a project to make multi-threading in Python more effective by getting rid of the CPython GIL, but I haven't heard anything in a while so I suspect they've given up.
Python threading works reasonably well for I/O-bound workloads, since you're not waiting while holding on to the GIL. So server workloads that aren't CPU-limited can be coded in Python fairly effectively.
FlamingSpaceJunk wrote:I don't particularly like using sub-processing. There's no guarantee the output is going to be machine parsable, and making CLI output human readable is en vogue these days.
Yeah, tell me about it... one of the defects I'm currently involved with (peripherally) at the day job looks like it may be a result of a Python program incorrectly parsing the output of a CLI command it launched. It happened in a production environment and most of the evidence got burned up in the resulting dumpster fire, so we're still in the "try to reproduce in an environment where we can capture the evidence" stage on that one.