Python is strongly typed, insofar as the term has a meaningful definition at all.

You meant "give me a statically typed language". Which may not actually be what you want, since statically typed languages can be, and some historically have been considered, weakly typed (C, for example).

doesn't strongly typed mean that the type cannot change once assigned? and you can do that in python, can you not?

No, again you're thinking of "static", not "strong".

Strong versus weak is historically poorly defined, and there's no single universally-accepted definition, but you can get the gist of it from considering the following:

    a = '1'
    b = 2
    c = a + b

In JavaScript, the above code results in the name 'c' being bound to the string value '12'. In Python, the above code raises TypeError. Generally, "weak" typing refers to the idea that the language may coerce the values of operands to other types in order to make an operation succeed (in the above, JavaScript coerced the value of 'b' to a string and interpreted the '+' operator as asking for string concatenation, hence the result is the string '12'). "Strong" typing generally means the language won't do that, and will error out on you if you attempt an operation on values of incompatible types.

"Static" versus "dynamic" typing is a completely different set of terms. There's also some debate over definitions, but broadly, consider the following expression:

    a = 1

In a statically-typed language, both the name 'a' and the value 1 have types, and in order to bind names to values their types must be compatible. So in the above, it's likely that both 'a' and 1 are of type int, so the assignment expression would be legal. Later attempting to bind 'a' to a value of a type incompatible with int (say, 'a = "foo"') would fail. Statically-typed languages also come with an expectation that all expressions can be checked for compatible types without needing to execute the code, and that a tool will exist to do this checking for you.

In a dynamically-typed language, however, only values have types; names do not, so binding a name to a value of a particular type does not foreclose later re-binding to a value of a different type (i.e., the name 'a' might be bound to an int now, and get re-bound to a string later). This means there will be cases in a dynamically typed language where the only way to verify correctness of an expression is to execute the code (though you can usually check a high percentage without running the code).

Python is strongly typed and dynamically typed.

Yeah distribution is a _huge_ problem for python right now.

Is it though? I mean, yes there is fragmentation and lots of old documentation but that's because Python is 25 years old and several approaches have been tried.

What's especially difficult about the following two steps?

  pip install pyinstaller
  pyinstaller main.py

The main problem isn't the solutions and efforts don't exist, but that core python doesn't care about it.

The core devs don't acknowledge distribution as a real issue -- which makes for a mediocre distribution experience.

Pyinstaller looks great like that, but gets extremely complex for anything serious.

There is another interesting approach on the horizon: https://github.com/Nuitka/Nuitka

Nuitka compiles your Python code to C and leaves you with a single file binary. It also improves performance.

Ubuntu 18.04, Miniconda 3.6 with Numpy etc. I tried Nuitka on my own project, it kept spinning for 20 minutes compiling Numpy dependencies. I eventually gave up and killed the process.

> pyinstaller main.py

One issue with PyInstaller is that it doesn't create a proper standalone binary. It either gives you a full directory tree or, with `--onefile`, an archive which self-extracts into such a tree.

I usually shudder at duck typing and/or GC for anything bigger. Both have the ugly tendency to explode in your face at runtime. The first type of error doesn't occur in C++ (at runtime), and in the other instance I feel like having more control. But maybe my academic experience with the two is to blame (multi-person projects in python (multiplayer game using lecturers lib) and Java (SQL DBMS, GC killed performance while in C++ I would have written a specialized allocator)).