The Python implementation can do whatever it wants because “Python” does not mean “The Python Language Specification”. It means the one specific implementation, and whatever that impl does is definitionally correct.
The ability for a language specification does to hand wave behaviour is very limited, and for JS is non existent (the only places where there is divergence between implementations is some squirrely edge cases of property and prototype chain mutation during for(in) enumeration).
So you can’t say “types mean whatever”, you have to specify what the implementation is required to do when it encounters those annotations. Even if they are not meant to have any semantic impact the lack of semantic impact must be specified: e.g the language specification would be required to state “here is the valid grammar for these annotations”, and specify that they are explicitly ignored and must not be evaluated or examined in any way.
> The Python implementation can do whatever it wants
No you're misunderstanding how it works in Python. This isn't like Rust where "the implementation is the specification".
The Python type checking standards explicitly don't define semantics (though I think they give guidelines). The standard Python implementation - CPython - does not include a static type checker. There is no "official" implementation.
In fact there are at least 4 Python static type checkers and they are all third party projects and they do differ in interpretation of types sometimes. The most popular ones by far are Mypy and Pyright (and Pyright is the far superior option).
So it is exactly the same as what is proposed for JavaScript. It definitely sounds mad and I do agree that it would be better if they just actually specified semantics, but not bothering isn't the complete disaster you might imagine.
No I think you’re misunderstanding my point, in your defense I was unclear: in an environment like JS you cannot leave anything as “it’s up to the environment” - the js engines must be 100% consistent which means the exact semantics of the syntax must be specified. E.g if you were to say add an optional type suffix to the language, say:
OptionalType := (‘:’ <Expression>)?
You have to specify what that means.
Does the expression get evaluated? E.g
let x : Foo.Bar = …;
Does this resolve Foo or subsequent property access of Bar.
Is the expression unrestricted? E.g could it be (a=>a)()
If you want something to be invoked at runtime you have to specify how and when that occurs (and you’re now going to have to specify what is being passed).
You have to specify when evaluation or calls happen, etc.
The problem for an environment like JS is you cannot add a language feature and not specify the exact behaviour.
E.g it’s not “you must define a type system” (though for the parties involved in pushing this when I was involved it would have been), it’s that even if you aren’t actually interested in defining a type system you have to do a lot of design and specification work because there cannot be ambiguity or gaps where different engines will disagree on what is valid, or will disagree on what portions result in any evaluation, or what semantic effects occur. The specification also needs to handle other things that don’t matter in the Python use cases: what happens if I do have a library that does type checking, but then my code is included in an environment that also does type checking but does it differently.
In Python it’s acceptable to say “don’t do that”, but in JS that’s not sufficient, the implementations need to agree on the result, so the result needs to be specified, and ideally the specification would need to provide semantics that simply support that.
Note that none of this is unsolvable, it’s just a lot of work, and not defining the type system doesn’t remove that specification work.
The Python implementation can do whatever it wants because “Python” does not mean “The Python Language Specification”. It means the one specific implementation, and whatever that impl does is definitionally correct.
The ability for a language specification does to hand wave behaviour is very limited, and for JS is non existent (the only places where there is divergence between implementations is some squirrely edge cases of property and prototype chain mutation during for(in) enumeration).
So you can’t say “types mean whatever”, you have to specify what the implementation is required to do when it encounters those annotations. Even if they are not meant to have any semantic impact the lack of semantic impact must be specified: e.g the language specification would be required to state “here is the valid grammar for these annotations”, and specify that they are explicitly ignored and must not be evaluated or examined in any way.