Yes when possible and feasible to know. And it's super easy to avoid everything Musk touches. Nothing he helms is without easy alternatives.

> maybe people don't want to take them out.

Maybe people no longer want to be seen in one.

Musk's politics and the fact that Cybertrucks didn't live up to any of its hype and turned into a heap of recalls didn't turn out to be the flex people thought it would be.

There's no reason your fingers should be under the blade while it's in motion. That's just poor technique.

If your blade is dull enough you’ll be using excess force to cut. People cut themselves regularly because they are using too much force and the thing they are trying to cut shifts and suddenly they have a finger under the blade. Or they are working with a dull paring knife and having to use too much force and it suddenly cuts and keeps going into their thumb.

Not everyone is a chef. I guess 80% of people in the world have poor technique for cutting stuff but they mostly get away not cutting themselves because they have dull knives.

I recently had to glue my thumb back on after I lopped it off with a Japanese knife while I was dicing vegetables. At my age, I have probably moved that knife millions of times and only cut myself once. Nobody can have a perfect record.

Had a friend do that recently. Knife freshly sharpened, took a dime sized hunk of his thumb right off. They stitched it back on, mostly to protect what was left underneath while it healed.

Only to those already steeped in Python. To an outsider they're all equally arbitrary non-descriptive words and there's not even obvious proper noun capitalization to tell apart a component from a tool brand.

It's always rather irritating to me that people make these complaints without trying to understand any of the under-the-hood stuff, because the ultimate conclusion is that it's somehow a bad thing that, on a FOSS project, multiple people tried to solve a problem concurrently.

That’s especially ironic given that inside Python part of the philosophy is “There should be one-- and preferably only one --obvious way to do it.” So why does Python’s external environment seem more like something that escape from a Perl zoo?

Because a lot of people have no clue about packaging or how to write compatible software, one that is actually installable as normal application. I suspect a lot of them learned stuff in node.js or ruby ecosystem first and this is the result. Same as requiring using docker to install or build an application. It isn't cool, funny or right way to do stuff. I still don't get what was so wrong about venv that anyone needed uv. I have no need to even try and i'm writing python stuff so long that i cannot even estimate it. To me it feels like reinvention for sake of rewrite in rust. If it is so good, ok, i get it, it might be - and all that good stuff needs to go back to python as python.

> I still don't get what was so wrong about venv that anyone needed uv.

Pip is slow, far slower than it needs to be in almost everything that it does, regardless of being written in Python. It's "standard" but not part of the standard library (so that it can be developed independently), and was never designed to install cross-environment properly (the current best approach, since 22.3, is a hack that incurs a significant delay and expects everyone to move in lock-step with the CPython EOL schedule). It wastes disk space, both by re-copying packages into new environments (rather than hard-linking them as uv does) and by spawning copies of itself in those environments (the original work-around to avoid needing cross-environment installation support, which a few people have also come to rely on in other ways).

> If it is so good, ok, i get it, it might be - and all that good stuff needs to go back to python as python.

I like these threads because they encourage me to work on my main project.

The one obvious way is the underlying virtualenv abstraction. Everything else just makes that part easier or more transparent.

What kstrauser said.

But with much more detail: it seems complicated because

* People refuse to learn basic concepts that are readily explained by many sources; e.g. https://chriswarrick.com/blog/2018/09/04/python-virtual-envi... [0].

* People cling to memories of long-obsolete issues. When people point to XKCD 1987 they overlook that Python 2.x has been EOL for almost six years (and 3.6 for over four, but whatever)[1]; only Mac users have to worry about "homebrew" (which I understand was directly interfering with stuff back in the day) or "framework builds" of Python; easy_install is similarly a long-deprecated dinosaur that you also would never need once you have pip set up; and fewer and fewer people actually need Anaconda for anything[2][3].

* There is never just one way to do it, depending on your understanding of "do". Everyone will always imagine that the underlying functionality can be wrapped in a more user-friendly way, and they will have multiple incompatible ideas about what is the most user-friendly.

But there is one obvious "way to do it", which is to set up the virtual environment and then launch the virtual environment's Python executable. Literally everything else is window dressing on top of that. The only thing that "activating" the environment does is configure environment variables so that `python` means the virtual environment's Python executable. All your various alternative tools are just presenting different ways to ensure that you run the correct Python (under the assumption that you don't want to remember a path to it, I guess) and to bundle up the virtual environment creation with some other development task.

The Python community did explicitly provide for multiple people to provide such wrappers. This was not by providing the "15th competing standard". It was by providing the standard (really a set of standards designed to work together: the virtual environment support in the standard library, the PEPs describing `pyproject.toml`, and so on), which replaced a Wild West (where Setuptools was the sheriff and pip its deputy).

[0]: By the way, this is by someone who doesn't like virtual environments and was one of the biggest backers of PEP 582.

[1]: Of course, this is not Randall Munroe's fault. The comic dates to 2018, right in the middle of the period where the community was trying to sort things out and figure out how to not require the often problematic `setup.py` configuration for every project including pure-Python ones.

[2]: The SciPy stack has been installable from wheels for almost everyone for quite some time and they were even able to get 3.12 wheels out promptly despite being hamstrung by the standard library `distutils` removal.

[3]: Those who do need it, meanwhile, can generally live within that environment entirely.

A dead project that was never popular to begin with gets to claim the word in perpetuity?

The fact that a single emitter traffic light that simply varies its color doesn't exist also disagrees with your statement.

Can't say I agree with the sentiment. Miryoku's layout looks pretty arbitrary, as is any other <60% setup. I daily drive a Planck (4 more total keys, but very similar levels of layout restrictions) and my layer designs are wildly different.

I would say just find or build a keyboard with support for Via or Vial so that you can change things on the fly when it feels wrong. If you're going down the small form factor keyboard path you're already committed to rewiring muscle memory, you might as well design your layout to meet your specific needs too. It's highly unlikely you will encounter someone else's Miryoku layout in the wild and need to type on it.

I don't think Miryoku is a good layout for many either, it will depend on your usage.

  A strange thing is that many come in to the small split keyboard world and then don't have the motivation to come up with something that works for them.   You can make anything work, so a lot make Miryoku work but I doubt for many that would be the best layout for them.

   I code a lot and find that its layout would not suit me. I have 99% of what I need on a the base layer and one more layer for doing development work - on a 36 key board.  I could not imagine that I would want to switch layers as much as I would have to  for a continuous stream of alphabet/symbols and numbers.

   I think Miryoku would be fine if you were an average computer user editing documents, emails etc and I do sometimes forget that there are a lot of guys out there using Miryoku doing only that.

I don't think this makes it much worse because that's hard to do, it's already terrible. Getting screwed by startup founders has been the status quo for at least 15 or 20 years now.

If you're just a worker then demand fair market wages, work healthy hours, and treat your useless class of shares as already used and discarded scratch off lottery tickets.

You're describing a 15 second effort that is performed at most once per phone purchase, and at its least once in the owner's entire history of iOS backup/restore processes. Less total effort than our comments took to write. You're then reading a whole lot into that.