41–50 of 57 posts
Strongly typed? You mean statically typed? See "What to know before debating type systems" : http://blogs.perl.org/users/ovid/2010/08/what-to-know-before...
> Type inference is generally a big win. I see this claimed a lot, but haven’t seen any evidence.
Earlier quoted context omitted.
I can import this with no errors, so Python is untyped: def foo(): return 1 + "2" Another example showing Python is untyped: x = 1 x = "2" x clearly has no type. No variables in python have types.
>>> 1 + "2" Traceback (most recent call last): File " ", line 1, in TypeError: unsupported operand type(s) for +: 'int' and 'str' https://dev.to/jiangh/type-systems-dynamic-versus-static-str...
The program '1 + "2"' is a perfectly valid python program with well defined behavior (it signals a TypeError). This demonstrates that you can in fact add integers to strings in python. Of course whether or not you can add integers to strings is completely orthogonal to whether or not a language is typed. Both typed and untyped languages may overload the addition operator.
Given that the OP is the github project owner, are you aware of https://chocopy.org/ ? You might want to also look at Shedskin, https://github.com/shedskin/shedskin which converts implicitly typed Python programs to C++
[1]: http://nuitka.net/
[2]: https://cython.org/
Given that the OP is the github project owner, are you aware of https://chocopy.org/ ? You might want to also look at Shedskin, https://github.com/shedskin/shedskin which converts implicitly typed Python programs to C++
No, I am not aware of ChocoPy. Thanks for letting me know. Shedskin uses the Python interpreter if I remember correctly. I aim not to.
I have nothing else to say except that I want this to happen. Python is an amazing language which is missing two things - static types and speed. I starred your repo and am looking forward to seeing it progress.
L = []
L.append(L)Earlier quoted context omitted.
>>> 1 + "2" Traceback (most recent call last): File " ", line 1, in TypeError: unsupported operand type(s) for +: 'int' and 'str' https://dev.to/jiangh/type-systems-dynamic-versus-static-str...
What that article calls "dynamically typed" is commonly referred to as "untyped" in PL research. The program '1 + "2"' is a perfectly valid python program with well defined behavior (it signals a TypeError). This demonstrates that you can in fact add integers to strings in python. Of course whether or not you can add integers to strings is completely orthogonal to whether or not a language is typed. Both typed and un…
"A type system is a tractable syntactic method ... Terms like 'dynamically typed' are arguably misnomers."
https://stackoverflow.com/questions/9154388/does-untyped-als...
I still prefer the term dynamically typed, because there are useful distinctions about value types to be made among such languages, such as those described in striking's link.
I was once toying with the idea to create a statically-typed Python-like language, and I had the perfect name for it: Typhoon... ;)
Alternate idea: a language called Typon in which the compiler paves over typos of keywords and symbol names.
Earlier quoted context omitted.
>>> 1 + "2" Traceback (most recent call last): File " ", line 1, in TypeError: unsupported operand type(s) for +: 'int' and 'str' https://dev.to/jiangh/type-systems-dynamic-versus-static-str...
What that article calls "dynamically typed" is commonly referred to as "untyped" in PL research. The program '1 + "2"' is a perfectly valid python program with well defined behavior (it signals a TypeError). This demonstrates that you can in fact add integers to strings in python. Of course whether or not you can add integers to strings is completely orthogonal to whether or not a language is typed. Both typed and un…
It's like the discussion is untyped, and the downvotes are runtime errors that would have been caught if terms were agreed upon ahead of time.