barubary

Again, "strong types" doesn't mean anything.

But from a type theory perspective, having "dynamic types" absolutely means you don't have a type system. All Python has is runtime exceptions. The fact that one of them is named TypeError doesn't make it a type error in the formal sense.

The point of a type system is not that variables have types, but that types are assigned to expressions (i.e. pieces of code in your source file), not to values (i.e. pieces of data). This is important because it guarantees that certain errors cannot occur in a program that passes the type checker (assuming you have a sensible/useful type system). And you get this assurance without running a single line of code.

To get a similar guarantee from Python, you need to write exhaustive tests, just as with any other runtime error.

"Strongly typed" is meaningless. (Or nearly so; in practice it means "I like this language" and "weakly typed" means "I dislike this language".) The point is that Python has no type system.

Python is un(i)typed.

Haskell.

Only since 2014, so barely over a decade.

CPU? It's called a modem!!

There's a lot of distorted facts here, but the weirdest one to me is "instead of regrouping their efforts (which, I might add, they did, and they got their day in parliament)". The first half just contradicts itself ("instead of doing X, which they did, ..."???) and the second half ("they got their day in parliament") is verifiably, obviously false: The EU petition is still ongoing and collecting signatures. The deadline is July 31.

@tetris11 @Aedis More like:

isEven() {    case "$1" in        *[02468]) return 0;;        *) return 1;;    esac;}

(If all the line breaks are gone from this code snippet, blame Lemmy. It looks fine here.)

If you were pair programming, your pair could always create a new failing test with the current implementation.

But I'm not pair programming. And you can't always create a new failing test because int is a finite type. There are only about 4 billion cases to handle.

Which might take a while to type up manually, but that's why we have meta-programming: Code that generates code. (In C++ you could even use templates, but you might run into compiler recursion limits.)

More to the point, the risk with TDD is that all development is driven by failing test cases, so a naive approach will end up "overfitting", producing exactly the code required to make a particular set of tests pass and nothing more. "It can't pass all test cases"? It doesn't have to. For TDD, it only needs to pass the tests that have actually been written. You can't test all combinations of all inputs.

(Also, if you changed this function to use modulus, it would handle more cases than before, which is a change in behavior. You're not supposed to do that when refactoring; refactoring should preserve semantics.)

When you say "it can't pass all test cases", what do you imagine the tests look like?

@devilish666 C++ (non-stupid):

#include <stdio.h>
int main() {
puts("Hello, world!");
}

Prost! 🍻