maksimum

This is good nuance to add to the conversation, thanks.

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.

A reference (that lays out the statistical arguments) is "Common Sense on Mutual Funds" by John Bogle.

What would you rather have for the next 5 years? Why?

Many reasons. Time value of money, competition, maybe even regulation.

Compared to __slots__ (also Python 3.7.4)

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)

Add __slots__

  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)

About 14% less time.

> The condition is, though, that I need to be able to quickly run the program to validate just all of it to work.

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.

TIL... Thanks for highlighting this.

> We've lost this battle.

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.

> It works in conjunction with the command line

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.

> I don't interpret this as charging different customers different prices per se.

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.

> more precisely predict what riders might be willing to pay for a ride

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?

Docker + setuptools/pip + python is great for development and production. Docker is definitely worth learning, and is pretty easy to learn.

It seems like long builds are either (a) necessary or (b) user error. (a) If you have a tree of dependencies and you change the root, you should rebuild everything that depends on it to make sure it's still compatible. (b) if you placed your application into one of the initial Dockerfile layers, but then you're installing dependencies that don't depend on you, it's user error.

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?

I think contemporary best practices start with the production environment and work backwards towards creating a development environment as close to the production environment as possible.

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.