Are the critiques in "All the things I hate about Python" valid?

[Antoon Pardon]

On 20-02-18 13:24, Steven D'Aprano wrote:
> On Tue, 20 Feb 2018 12:18:47 +0100, Antoon Pardon wrote:
>
>> On 19-02-18 15:25, Steven D'Aprano wrote:
>>>> Ones like C++ has already tied itself itself up in knots just doing
>>>> the basics; I'm not sure how it would handle even my 1,3,5,7,9 type.
>>>>
>>>> But Python has classes and can do some of this stuff; how would it
>>>> handle a numeric type that is constrained to be whole numbers within
>>>> 0..9 inclusive?
>>> This becomes easy at run-time:
>>>
>>> class Digit(int):
>>>     def __new__(cls, arg):
>>>         instance = super().__new__(cls, arg)
>>>         if not 0 <= instance <= 9:
>>>             raise ValueError('argument is out of range')
>>>         return instance
>>>
>>> The above is obviously not a full-blown production-ready class. But it
>>> illustrates the basic concept. This is the sort of thing that dynamic
>>> languages excel at: enforcing constraints at run-time which are hard to
>>> enforce at compile-time.
>> I don't see how dynamic languages are excelling here. Writing code that
>> ensures a number of constraints can be done just as easily in a static
>> language.
> *Just* as easily? Really?
>
> Can you tell us which languages can enforce at compile-time that integer 
> N is a multiple of four but not a multiple of 100 unless it is also a 
> multiple of 400? (The same constraint as leap years.)

Why should this be done at compile time? I say a static language can do
the same as a dynamic language and your counter point is to ask for how
that static language can do something extra.

The point I am making is that you claim dynamic languages are excelling
by being less demaning of the dynamic language.

So yes the static language can check those kind of restraints at runtime
just as easily as a dynamic language.

> What type declaration would you write for that?
>
> Its easy to make overblown claims about how great static typing is, but 
> people didn't invent dynamically typed languages because they wanted to 
> program in a worse language. They did it because dynamic typing allows us 
> to do things which are hard, or impossible, in statically typed languages.

Maybe but you didn't give an example of something that is hard of impossible
in a statically typed language. There is nothing impossible or hard in checking
a number of constraints during runtime in a statically typed language.

> I agree that Pascal-style interval types are nice, but they're also 
> limited to intervals, and *integer* intervals at that. Pascal doesn't 
> support floating point ranges, such as "x is a Real between 0 and 1".
>
> How would you write a type declaration for numbers like these:
>
>     4, 6, 8, 24, 26, 48, 50, 124, 126, 342, 344, ... 3909821048582988050
>
> in the language of your choice?
>
> Yes, there is a pattern: one less than, and one more than, powers of 5 
> and 7, up to a maximum of 2**64.
>
> That is, 5±1, 25±1, 125±1, ... 7±1, 49±1, 343±1, ...

Well as far as I know you could do this in C++ by having the constructor and
copy-operator make the needed checks.

> Its one thing to say that a type system could enforce this at compile-
> time. Its another to demonstrate an existing type system which actually 
> does.

I am not talking about compile time. There is nothing that prevents a
statically typed language to do some of the checks at runtime.

>> Each assignment to x would then implicitly do something like an assert
>> to checks the constraint,
>> so it would be impossible to ever assign 11 to x, without an error being
>> thrown.
> As I remember it, Pascal range checking is just dynamic typing in 
> disguise. Statically, x is just an integer, with no interval checking 
> performed at compile-time except for assignment by literals. Everything 
> else is run-time range checking.

So? As far as I know Pascal is generally considered a statically typed
language. That some of the constraints imposed by the type can only
be checked at runtime doesn't contradict that the type of a variable
is determined at compile time.

> Of course you're right that Python won't stop you assigning (say) a float 
> to x. On the other hand, Pascal and C won't allow you to assign a string 
> to something which previously was an integer. The need to create new 
> labels for things just to placate the compiler is one of the more 
> annoying things about static typing. Yes, x was a number, now its a 
> string. If *I* can keep track of that, why can't the compiler?

Is it really that annoying? Most examples I have seen here where the
same variable was assigned multiple types, was labeled a code smell
that needed to be approved by review or something like that, on this list.

People praise the dynamic nature of Python here on this list and then
often enough seem to recoil when they see a piece of code really using
that dynamism.