I think its typical that only one python runtime is installed in the system. What is the use case for bundling the runtime with the app?

I'm one of the rare idiots who wrote a consumer-faced python+Qt program. I need to ship the right dependencies along with the right version of python to my customers.

Using Pyinstaller it works out in the end, but after everything, it would have been better to use a language meant for user-facing applications.

I package Captain's Log [0] with PyInstaller.

I need to, because otherwise I wouldn't be able to package it for Windows users.

The app is also closed source.

I cannot easily package the application for Linux users, because of so many different flavours of Linux, so many different combinations of Python and Qt versions.

Which is why I've given up on a pure Linux version and I'm in the middle of adapting it to work under WINE alongside Elite: Dangerous also running under WINE, instead.

[0] https://captainslog.scarygliders.net/captains-log-2/

Many systems still have both Python 2 and Python 3 installed. Also, in the standard case, the version of Python is controlled by the user, not by your app. Bundling it with the app lets you make sure that it's running Python 3.8, for example, so that you can use Python 3.8 features without having to add a bunch of compatibility shims in case the user is running an older version.

Distribute my cli app + gooey as a stand-alone binary for windows users

Perhaps on a server, but on my workstation I probably have 6 or 7 pythons installed.

edit: including virtualenvs and conda environments have 41 python.exe files on my workstation right now.

No there’s often tons of them. I’ve personally seen hundreds.

Roughly 0% of Windows users have Python installed.

This may seem like a good idea, but it gets problematic since you need to always use isinstance checks. Its actually discouraged to return union types by the mypy team: https://github.com/python/mypy/issues/1693

Yeah, but you need to test whether the result is an error or not in some way. In languages with better ADT/pattern matching support (like Haskell or Rust) you'd use case/match operator, or whatever it's called.

I've read the issue, and it seems that it's more about the lack of overloading/dependent types, e.g. their example with pow function. In c++ you'd have two overloads:

    float pow(float, float)
    int pow(int, int)

Whereas in python, even though you can achieve the equivalent behaviour in runtime, mypy (at least until recently) couldn't express this, so you had to define something like

    def pow(base: Union[int, float], power: Union[int, float]) -> Union[int, float]

Which might be annoying on call sites when you do expect the return type to be int (but there is no way for mypy to know that with such signature).

In my case I do want to return a variant type unconditionally, so this warning doesn't really apply. It's more similar to an Optional type (just instead of None I am using a more meaningful Exception): while it's not great if your code is riddled with optional return types, sometimes you don't have other choice but using it.

You can use typing.TypeVar for the `pow()` example. TypeVar was added via the original type hints PEP in 2014.

    from typing import TypeVar

    T = TypeVar('T', int, float)
    def pow(base: T, power: T) -> T: ...

Python's static type system can express what you describe using TypeVars or overloads. The issue is that `int pow(int, int)` is fundamentally incorrect. If the exponent is a negative integer, the return type would need to be float.

As evidenced by your comment, most people forget about negative exponents. The vast majority of usage is positive exponents; people expect an int back when they do `pow(2, 2)` and returning a Union or float would result in annoying false positives.

ISO8601 is quite large, they probably don't want to ship that big standard library modules which would parse 100% of ISO8601

Scripts which generate the config also have their own problems. Check out Dhall, it attempts to solve this.

Reminds me a bit of jsonnet (https://jsonnet.org/) which didn't catch on much as far as I can tell.

I see very little practical value in a DSL like this. Using an existing language with an extensive ecosystem and great tooling was half the point of wanting TypeScript in the first place. Most of the "risks" can be handled with just a few eslint rules, tests (e.g. all outputs must satisfy a set of constraints), and code review.

Especially when the moment you need to do more than just generate config files (e.g. fetch some information from an external service, or even write an imperative script for the occasional task), you'd have to switch to a different langauge and all its tooling - where you can't just import the exact same type definitions, etc.

I think docker is great for providing isolated environment, venv has similar goals. pip-tools + docker is powerful combination, but the article doesnt mention pip-tools for some reason.

docker with pip-tools is great combination, you get deterministic builds easily

Just FYI: google recaptcha works with screen readers too and blind users can use it.

What kind of videos you watch? Maybe that could guide you to find something which interests you.

I recently heard the advice to do some forensics on yourself -- bookmarks, search history, youtube history, to figure out what kind of person you are (in the context of what work would suit you best).

That and why not allow null for the foreign key constraint and set it to nullify upon deletion? Or indeed, anonymise data.

I have used that pattern in my apps and found it works well. But then I've watched video from respected DB experts, that I learn a great deal from, where they practically beg you to stop using nullable columns.

So I'm torn, because I think there may just be a major problem I've not yet grown my apps big enough to suffer. Anyone have thoughts either way?

Any particular videos you'd recommend?

> Not using foreign key constraint just for the sake of GDPR sounds weird.

That isn't what he said.

He said their inability to delete an account is due to poor design of their data schema by a well intentioned developer.

I tried to search for "cheese without holes" on Google and it yielded good results. I think the problem here is that the query is something people would rarely search.

I just searched google images for "cheese" and "cheese without holes" and I got roughly the same results (about 1/3 of the images had holes in both cases).

"pictures" and "pictures without color" show that it does get some of these, although not the way I expected.

If that's the case that's a big problem, because human children are trivially capable of both formulating and understanding uncommon sentences which still make sense.

It might be hard to come up with examples on the spot, but in everyday life you will routinely come across things you need to refer to by negation which are relatively uncommon.

Human children are also capable of walking, but it’s one of the hardest problems in robotics. Things brains can do intuitively, they can do because they have millions of years of evolution behind them.

Of the things the human brain does, I wouldn't say walking is very interesting.

The most amazing property in my opinion is the fact that it trains itself. (Whereas neural networks are trained by external systems).

I suspect it's related to imprinting. To take the example of filial imprinting, the brain must have some hardcoded notion of what a parent looks like. Then this is used to to build a parent detector, and the hardcoded notion is thereafter discarded. Then the newly learnt parent detector is used in reinforcement learning (near parent = good). Keep in mind that this all happens just after birth or hatching, before the visual centres of the brain have had any chance to train.

Really cool stuff.

THat will be your search bubble. You clearly prefer Stilton or Chedder to Emmental cheese