9 ms·

Python is strongly typed. It is also dynamically typed, and many people get the two confused.

willtim 9y ago
The confusion is no doubt intentional in order to make dynamic languages sound safer than they really are. There really is only one type: PyObject.
- acdha 9y ago
  This statement wouldn't be helpful even if wasn't incorrect. You clearly don't like Python but accusing other people of malice for not sharing your personal taste is not going to accomplish whatever you believe it will.
  - deleted 9y ago
    [deleted]
  - willtim 9y ago
    This is about being open and honest to stakeholders about Pythons strengths and weaknesses. Sure, I won't ever get the terminology used in your community to change, but at least you will know that there are people who find it rather uncomfortable and disingenuous.
    - acdha 9y ago
      Disingenuous is lying about people’s motives to make your opinion seem more like a truth. It’s okay not to understand Python or typing as well as you think but that should be a chance to learn rather than your cue to accuse people of malice for giving the world free software.
      - willtim 9y ago
        Go read the link I posted by Professor Robert Harper before accusing me or anyone else of not understanding type theory. Whether you like it or not, technology does compete for mindshare. Haskell and OCaml are also free software.
        acdha 9y ago
        Prof. Harper didn’t mention Python. He definitely didn’t accuse people of dishonest advocacy. Stop using his name to support your comments. You could try to do something positive like talk about how Haskell does something neat which Python doesn’t support. I can think of several examples which are far more interesting than arguing over whether your personal definition of “strong typing” is universally shared.
        willtim 9y ago
        > He definitely didn’t accuse people of dishonest advocacy. Have you actually read it? "Like most marketing tactics, it’s designed to confuse, rather than enlighten, and to create an impression, rather than inform."
        acdha 9y ago
        You really aren’t willing to avoid personal attacks, are you? It’s not doing anything productive. The main thing I took away from that post was his belief that the static / dynamic divide was a false dichotomy. I do agree, however, that I was incorrectly remembering it too charitably: he and you are both willing to distract by accusing other people of acting in bad faith without bringing evidence to support such a strong accusation.
        willtim 9y ago
        I missed off a smiley, nothing personal was meant by it. Some of your posts have appeared abrasive too. Let's just agree to disagree.
zenhack 9y ago
"getting the two confused" implies that your terminology is standard, which it isn't. It is also quite common to use the term "type" to refer exclusively to properties that are checked statically. Arguably "strong dynamic typing" is a property of libraries, not languages -- e.g. int conceptually has a method like: def __add__(self, other): if not isinstance(other, int): raise TypeError(...) return _unchecked_add_ints(self, other) It's implemented in C for efficiency, but that's basically the semantics. Critically, this doesn't magically extend to user-written libraries, so unless you actually write all of that boilerplate nothing but a handful of methods in the standard library can be claimed to be "strongly typed". I've written code with a bunch of asserts in methods like that after determining that a large percentage of bugs were type errors that were silently doing the wrong thing. Without something like mypy, Python is untyped by any reasonable definition; it provides no support for users to actually work with types in any meaningful way.
- viraptor 9y ago
  I think you got the user-written part the wrong way around. It is strongly typed because unless you define the operators/methods you explicitly want to enable, they don't exist. For example if you try "object() + object()", you get an exception. You can implement the addition in a subclass, but that's explicit then. Compare to JS where "new Object() + new Object()" results in a string by default.
  - zenhack 9y ago
    You only get an exception if and when something in the bowels of your implementation bangs into a low-level operation that has one of these checks in it. For example: >>> import subprocess >>> subprocess.call([2]) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.7/subprocess.py", line 172, in call return Popen(*popenargs, **kwargs).wait() File "/usr/lib/python2.7/subprocess.py", line 394, in __init__ errread, errwrite) File "/usr/lib/python2.7/subprocess.py", line 1047, in _execute_child raise child_exception AttributeError: 'int' object has no attribute 'rfind' In the case of `object() + object()`, that check is in `object.__getattribute__` My point is that the checks are a property of a definition of those (possibly built-in) classes; the language doesn't provide any facility to talk about types as such. Nothing in the language knows that the argument to subrpocess.call should be a list of strings, it just happily executes until it hits what is essentially: >>> (2).__getattribute__('rfind') Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'int' object has no attribute 'rfind' And `__getattribute__` throws an exception. This is the best case scenario. Worst case it never hits something that these primitive types are aware is not ok, and it just does the wrong thing. There's no way to specify typing invariants in a way the language understands -- you just have to put in the manual check yourself. This is what I mean when I say strong types aren't part of the language. But if you add static types to the mix (say via mypy): If it were actually checking what should be the types involved in the code you wrote you'd get something like this: error: List item 0 has incompatible type "int"; expected "Union[bytes, str, _PathLike[Any]]" ...which is what mypy reports when run on that code. Python isn't checking the type of the argument subprocess.call ever, not even at runtime. If you're lucky, eventually you hit some code that has an explicity sanity check in it and it raises an exception. There's an interesting point in the design space that you see with julia[1], and also with mechansims like racket's contracts[2], where the types aren't checked statitcally, but they are checked at runtime, unlike the example above with subprocess, where you only get the error deep in the implementation when something actually explodes. I think you could sensibly say that the "strength" is actually a property of Julia, rather than its libraries, but not in Python, the "strength" isn't part of the language per se. The only differece with a "weakly typed" language is that those basic libraries have a much more footgun-like design -- again, not really about the language per se. [1]: https://docs.julialang.org/en/stable/manual/types/ https://docs.julialang.org/en/stable/manual/types/ [2]: https://docs.racket-lang.org/reference/contracts.html https://docs.racket-lang.org/reference/contracts.html
naasking 9y ago
There is no such thing as "strong typing", so no language has that feature. Perhaps you mean it's type safe in some dynamic sense, but strong and weak are not qualifiers that have any kind of rigourous definition in type systems.
- imtringued 9y ago
  Usually what is meant by weak and strong typing is that there are a lot or few implicit conversions between types which undermine the typesystem. Imagine an esoteric language which automatically converts any type into any other type. For the conversion the language will pick the default value for that type or if there is no default value it will pick null. How useful would the typesystem be in this case?

The confusion is no doubt intentional in order to make dynamic languages sound safer than they really are. There really is only one type: PyObject.

acdha 9y ago
This statement wouldn't be helpful even if wasn't incorrect. You clearly don't like Python but accusing other people of malice for not sharing your personal taste is not going to accomplish whatever you believe it will.
- deleted 9y ago
  [deleted]
- willtim 9y ago
  This is about being open and honest to stakeholders about Pythons strengths and weaknesses. Sure, I won't ever get the terminology used in your community to change, but at least you will know that there are people who find it rather uncomfortable and disingenuous.
  - acdha 9y ago
    Disingenuous is lying about people’s motives to make your opinion seem more like a truth. It’s okay not to understand Python or typing as well as you think but that should be a chance to learn rather than your cue to accuse people of malice for giving the world free software.
    - willtim 9y ago
      Go read the link I posted by Professor Robert Harper before accusing me or anyone else of not understanding type theory. Whether you like it or not, technology does compete for mindshare. Haskell and OCaml are also free software.
      - acdha 9y ago
        Prof. Harper didn’t mention Python. He definitely didn’t accuse people of dishonest advocacy. Stop using his name to support your comments. You could try to do something positive like talk about how Haskell does something neat which Python doesn’t support. I can think of several examples which are far more interesting than arguing over whether your personal definition of “strong typing” is universally shared.
        willtim 9y ago
        > He definitely didn’t accuse people of dishonest advocacy. Have you actually read it? "Like most marketing tactics, it’s designed to confuse, rather than enlighten, and to create an impression, rather than inform."
        acdha 9y ago
        You really aren’t willing to avoid personal attacks, are you? It’s not doing anything productive. The main thing I took away from that post was his belief that the static / dynamic divide was a false dichotomy. I do agree, however, that I was incorrectly remembering it too charitably: he and you are both willing to distract by accusing other people of acting in bad faith without bringing evidence to support such a strong accusation.
        willtim 9y ago
        I missed off a smiley, nothing personal was meant by it. Some of your posts have appeared abrasive too. Let's just agree to disagree.

zenhack 9y ago

"getting the two confused" implies that your terminology is standard, which it isn't. It is also quite common to use the term "type" to refer exclusively to properties that are checked statically. Arguably "strong dynamic typing" is a property of libraries, not languages -- e.g. int conceptually has a method like: def __add__(self, other): if not isinstance(other, int): raise TypeError(...) return _unchecked_add_ints(self, other) It's implemented in C for efficiency, but that's basically the semantics. Critically, this doesn't magically extend to user-written libraries, so unless you actually write all of that boilerplate nothing but a handful of methods in the standard library can be claimed to be "strongly typed". I've written code with a bunch of asserts in methods like that after determining that a large percentage of bugs were type errors that were silently doing the wrong thing. Without something like mypy, Python is untyped by any reasonable definition; it provides no support for users to actually work with types in any meaningful way.

viraptor 9y ago
I think you got the user-written part the wrong way around. It is strongly typed because unless you define the operators/methods you explicitly want to enable, they don't exist. For example if you try "object() + object()", you get an exception. You can implement the addition in a subclass, but that's explicit then. Compare to JS where "new Object() + new Object()" results in a string by default.
- zenhack 9y ago
  You only get an exception if and when something in the bowels of your implementation bangs into a low-level operation that has one of these checks in it. For example: >>> import subprocess >>> subprocess.call([2]) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.7/subprocess.py", line 172, in call return Popen(*popenargs, **kwargs).wait() File "/usr/lib/python2.7/subprocess.py", line 394, in __init__ errread, errwrite) File "/usr/lib/python2.7/subprocess.py", line 1047, in _execute_child raise child_exception AttributeError: 'int' object has no attribute 'rfind' In the case of `object() + object()`, that check is in `object.__getattribute__` My point is that the checks are a property of a definition of those (possibly built-in) classes; the language doesn't provide any facility to talk about types as such. Nothing in the language knows that the argument to subrpocess.call should be a list of strings, it just happily executes until it hits what is essentially: >>> (2).__getattribute__('rfind') Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'int' object has no attribute 'rfind' And `__getattribute__` throws an exception. This is the best case scenario. Worst case it never hits something that these primitive types are aware is not ok, and it just does the wrong thing. There's no way to specify typing invariants in a way the language understands -- you just have to put in the manual check yourself. This is what I mean when I say strong types aren't part of the language. But if you add static types to the mix (say via mypy): If it were actually checking what should be the types involved in the code you wrote you'd get something like this: error: List item 0 has incompatible type "int"; expected "Union[bytes, str, _PathLike[Any]]" ...which is what mypy reports when run on that code. Python isn't checking the type of the argument subprocess.call ever, not even at runtime. If you're lucky, eventually you hit some code that has an explicity sanity check in it and it raises an exception. There's an interesting point in the design space that you see with julia[1], and also with mechansims like racket's contracts[2], where the types aren't checked statitcally, but they are checked at runtime, unlike the example above with subprocess, where you only get the error deep in the implementation when something actually explodes. I think you could sensibly say that the "strength" is actually a property of Julia, rather than its libraries, but not in Python, the "strength" isn't part of the language per se. The only differece with a "weakly typed" language is that those basic libraries have a much more footgun-like design -- again, not really about the language per se. [1]: https://docs.julialang.org/en/stable/manual/types/ https://docs.julialang.org/en/stable/manual/types/ [2]: https://docs.racket-lang.org/reference/contracts.html https://docs.racket-lang.org/reference/contracts.html

naasking 9y ago

There is no such thing as "strong typing", so no language has that feature. Perhaps you mean it's type safe in some dynamic sense, but strong and weak are not qualifiers that have any kind of rigourous definition in type systems.

imtringued 9y ago
Usually what is meant by weak and strong typing is that there are a lot or few implicit conversions between types which undermine the typesystem. Imagine an esoteric language which automatically converts any type into any other type. For the conversion the language will pick the default value for that type or if there is no default value it will pick null. How useful would the typesystem be in this case?