I think in most cases you have to trust some group of parties. As an individual you likely don't have enough time and expertise to fully validate everything that runs on your hardware.

Do you trust the OSS community, hardware vendors, OS vendors like IBM, Apple, M$, do you trust third party vendors like Crowdstrike?

For me, I prefer to minimize the number of parties I have to trust, and my trust is based on historical track record. I don't mind paying and giving up functionality.

Using your definition of class X

  %timeit x.w()
  313 ns ± 18.3 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

  class X:
    __slots__ = ('a')
    def w(z):
      a = z.a
      return a+a+a+a+a

  %timeit x.w()
  271 ns ± 7.13 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

That's a condition for all TDD.

> I know there's testing frameworks, although it seems more of an eclectic mess than Java

If you look at the test suites for popular libraries like numpy, django, airflow it's mostly `pytest`, `unittest` (part of the standard library), and `nose`.

> where testing and mocking is just a little harder to do...

Mocking is actually pretty easy to do in python using pytest.monkeypatch or unittest.mock. Compared to mocking in a strongly typed language like C++ (and I assume Java) if an object you're mocking implements a particular interface, you would only have to mock out the parts that get exercied by the codepath in the tests you care about.

I think you could look at the battle/war from a different perspectives, and come up with different conclusions.

In the mainstream (whatever that is?) it appears that convenience wins. And hardware/software vendors seem to make the assumption that customers won't complain if their data is harvested. I think that's where you're coming from?

On the (privacy) enthusiast things, the horizon looks much better. We've got great software that makes self-hosting easier: FreeNAS, Nextcloud, Docker, Plex, NixOS, etc. We have more choice in phones: we can still use "dumbphones", or use open source operating systems, or choose manufacturers with better privacy track records. I'm not familiar with consumer electronics as much, but buying low end/dumb devices (TVs, appliances) is still viable. And the open source home automation movement keeps getting traction with hardware and software.

According to [1] using 3 letters you'd need at least 72 commits to have at least 50% chance to observe a clash. Using 6 letters you'd need at least 3977 commits, lol.

[1] https://en.wikipedia.org/wiki/Birthday_problem#The_generaliz...

Do you know of git GUIs that explicitly maintain a bijection between the GUI and the underlying command history? It'd be cool to use the GUI and see the command history, or use the CLI and see updates in the GUI.

Based on my experience Lyft and Uber charge different prices to different customers with identical trips. I've tested this by asking friends with who I'm about to share a ride with to request the same trip as me, and compare prices. We've observed differences of 10-20%.

> Knowing what your service is worth to customers so you can extract a greater fraction of this is pricing 101.

Where this becomes problematic is in the age of big data. When a company can build an accurate profile of me, they can extract maximum prices from me. We need laws that mandate what definition of "profile" is allowed to be used for pricing.

I'm not sure why we accept price discrimination at the individual level for airlines and Lyft/Uber. I'm pretty sure people would be outraged if Amazon started price discriminating based on your purchase history.

It's weird to me that this sort of price discrimination is legal.

E.g. given this information, my incentive as a rider is to never tip (so that their algorithm doesn't identify me as "willing to pay" more). Maybe I could also make a new Lyft account every time I need a ride?

What's the situation where your application needs to go first in the Dockerfile, and then you need to put a bunch of stuff that doesn't depend on your application?

These days, most productions environments are effectively isolated containers. If your production environment is a container, you probably should develop in a container as well. In that case you don't need much tooling for isolating an application's dependencies from other applications.

The tooling that you need is to build a python application, which means (1) get the dependencies (2) copy over some source code (or invoke the C-compiler if build a C<->Python extension) (3) run tests. Python's builtin setuptools does that fine. It didn't strike me as amazingly simple, but it's not amazingly complex either. pip is essentially a convenience wrapper for setuptools, i.e. pip is to setuptools as apt is to dpkg.

Basically, I believe that because of docker isolation is a irrelevant criterion by which to judge a language/ecosystem.

I imagine if you're deploying docker, you probably should be developing in docker (e.g. using PyCharm's remote interpreter/docker interpreter integration).

Do you think private browsing sessions are also unclear/have unintuitive UX? It seems like firefox containers are just private browsing sessions that you can close and re-open.

They publicly describe a habit that they claim is useful. To me that implies that they're suggesting others invest time into the habit.

But I've never been compelled by the arguments. I haven't seen someone try to make (even qualitatively) refutable claims. If you don't make refutable claims, how can I experiment in order to see whether the habit makes sense for me?