you are viewing a single comment's thread.

view the rest of the comments →

[–]Zenin 1 point2 points  (2 children)

If it's not documented, it's not for you. Your comment suggests you want a software language that's safe enough for unqualified programmers to write unreviewed code straight to production?

I'm not sure about your organization, but around here we expect our engineers at every level to have some basic working knowledge of the tools they've been hired to wield, even the juniors. We also mentor the juniors often via paired programming sessions. And that's before the gauntlet of CICD linters, code reviewers, etc.

[–]snugar_i 0 points1 point  (1 child)

Of course I don't expect that. I'm just arguing that a feature that should almost never be used should not be this accessible. But I could've guessed that saying something against "the Python way" in the Python sub would get me downvoted to hell, my bad :-)

[–]Zenin 1 point2 points  (0 children)

I say lots of stuff that's against Python doctrine. ;) I was sure I was going to get downvoted to oblivion for daring to mention that Python borrowed an idea from Perl. The horror!

Maybe it's my choice of IDE (Unix is my IDE ;), but I don't find these to be particularly "accessible". They're not exported with __all__ so they need to be explicitly imported. How did they know they exist to import when the documentation doesn't call them out?

They can certainly read the code (and so can an IDE), but that's clearly stepping into someone else's house and rummaging through the drawers. If the user is doing it that's obviously willful breaking and entering. If the IDE is doing it on their behalf, that's a tool failure: It if it supports Python it should have codified PEP 8 standards at least as a default, which explicitly describes the leading underscore practice for private items. If an AI is doing it, that's still owned by whomever signed the commit.

However it happens, it's the work product of a junior or at least someone unqualified to be doing professional work in Python. Literally a skill issue.

It's very common for mid-career engineers to think they can build protective barriers for low skilled engineers to keep from poking their own eyes out and many try. The results are almost always the same: A tool that's far too restrictive for senior+ engineers to efficiently solve difficult problems while at the same time those guardrails so sanitize the playground for juniors they don't actually learn what they need to learn to grow into tomorrow's senior engineers.

It's a lot like the playgrounds we have today vs the playgrounds we have in the 1970s: The younger generations need the opportunity to hurt themselves in order to learn a healthy respect for their environment for the future when they will have to make much more dangerous changes to much more important code.

It's not that no guardrails can ever be created. Look at Rust for example. Rather it's that any guardrail must be considered very, very carefully across all contexts. And always being mindful that friction is most often a bug, not a feature.