7 ms·
Python is 'strongly' typed `dynamic` language!!!
by palerdot 7y ago
Python is 'strongly' typed `dynamic` language!!!
- jsjddbbwj 7y agoNo, Python is not strongly typed by any serious definition of the concept.
- Karunamon 7y agoIsn't the existence of TypeError and the various things you're not allowed to do implicitly (eg: 1 + "a", something Javascript will happily let you do) a definition of strongly typed?
- ben509 7y agoIf it's qualified as a "serious definition," they're setting up a No True Scotsman argument.
- kybernetikos 7y agoJavascript has type errors too, and Java will let you 'add' a string to an integer, so it's more nuanced than that... Javascript: > null.bob() TypeError: Cannot read property 'bob' of null > 4 >>> Symbol("four") TypeError: Cannot convert a Symbol value to a number > BigInt(null) TypeError: Cannot convert null to a BigInt > Object.create(false) TypeError: Object prototype may only be an Object or null: false Java: int anInteger = 10; String s = anInteger + "Hello";
- msla 7y agoIt is in that you can't "peel off" the type system using casts, as you can in C and Java.
- blattimwind 7y agoStrongly typed: >>> "foo" + 3.141 TypeError: can only concatenate str (not "float") to str >>> object() + 3.141 TypeError: unsupported operand type(s) for +: 'object' and 'float' Weakly typed: > "foo" + 3.141 "foo3.141" > Object() + 3.141 "[object Object]3.141" > [] + {} "[object Object]" > {} + [] 0
- msla 7y ago> "foo" + 3.141 "foo3.141" How is this weakly typed when it uses type information to work? No, this is strongly typed.
- jsjddbbwj 7y agoa = 3 a = 'abc' There goes your strength, Samson. Just because there's something worse, that doesn't make python strongly typed
- blattimwind 7y agoYou are conflating weak/strong-typing with static/dynamic-typing. These are largely orthogonal.
- Macha 7y agofn main() { let x = 1; let x = "foo"; } Does this make rust not strongly typed? Here's a Rust program with no types in the source code. It seems the issue you're objecting to is that python doesn't differentiate variable declaration from assignment (The fact we need let twice in this code is a result of Rust doing this). Which is a fair thing to complain about (and why Python had the "nonlocal" and "global" keywords), but is not the same as being strongly or weakly typed.
- steveklabnik 7y agoThat's not an identical translation, the identical Rust would be fn main() { let mut x = 1; x = "foo"; } which indeed fails to compile with a type error. (That being said there is a conflation of static/dynamic and weak/strong going on in this thread, as there always is in these kinds of discussions.)
- joshuamorton 7y agoI'd disagree that this is a better translation. In python-land, `x` is just a name binding. The closest thing might be that `x` is something akin to a Box<T>, but I don't know that that's cleanly expressible in rust. Like in (modern) python you can totally do def foo(): x: Union[str, int] = 1 x = "foo" which would be akin to in rust ?? (sorry my rust foo isn't great). Specifically the semantics don't work here because if you do ~this: def foo(): x = 1 async takes_int(x) x = "foo" this will always work find in python (even in a hypothetical GIL-free python, even if you make the assignment actually async), whereas that wouldn't work in rust if you pass a mutable ref to takes_int (at least if memory serves). Or I guess another way of putting this is that names in python can't be mutable.
- tynorf 7y agoCurious: what is your definition of strongly typed, contrasted with weakly typed? How about static vs dynamic?
- strbean 7y agoI'd guess that parent doesn't agree with calling a duck-typed language strongly typed. If so, I concur.
- hope-striker 7y agoHere is the most common definition of strong typing, and below it an assertion that "Smalltalk, Perl, Ruby, Python, and Self are all strongly typed". https://en.wikipedia.org/wiki/Strong_and_weak_typing#Implicit_type_conversions_and_%22type_punning%22 https://en.wikipedia.org/wiki/Strong_and_weak_typing#Implici...
- strbean 7y agoThat is quite a disingenuous quote... the actual content is: > Smalltalk, Perl, Ruby, Python, and Self are all "strongly typed" in the sense that typing errors are prevented at runtime and they do little implicit type conversion, but these languages make no use of static type checking: the compiler does not check or enforce type constraint rules. The term duck typing is now used to describe the dynamic typing paradigm used by the languages in this group. That is quite a qualified usage. The only feature distinguishing Python from Javascript here is that Python does less implicit type conversion (where it is reasonable v.s. where it is insane). In every other dimension it is the same.
- ric2b 7y agoDo you have an example of Python doing implicit type conversion?
- kragen 7y agoPython2 implicitly converts int to long and str to unicode: >>> 2**100 1267650600228229401496703205376L >>> 'x' + u'y' u'xy' All Pythons implicitly convert int to float and int or float to complex: >>> 1 + .5 1.5 >>> 2 * 3j 6j Methods like list.extend now, in recent versions of Python (since 2.1), accept arbitrary iterables rather than just lists; it's more debatable whether this is an “implicit type conversion” or not. >>> x = [3, 4]; x.extend((5, 6)); x [3, 4, 5, 6]
- strbean 7y agoThanks for the examples. I was mainly thinking of int-float conversion that is present in the vast majority of languages.
- hinkley 7y agoThere are two technical conversations I don't have because everybody just gets mad and nothing gets resolved. (Note to reader: if you haven't guessed already, this means I am not going to be reading replies to this thread and certainly not responding to them. Go outside and get some air.) One, the Monty Hall problem. You either get it or you will die on a hill of misunderstanding. I've never seen anyone's mind be changed (I had to change my own mind). Statistics are really fucking hard. Two, that the differences between the Java Language Spec and the Java Virtual Machine spec mean that Java is not quite as statically, strongly typed as you think. There is code that you cannot (re-)compile that runs just fine, for some useful definitions of 'fine'. To support lazy loading of classes, and reduce inter-version dependency hell, the first invocation of every function is dynamically dispatched, and the result is memoized. It's not Duck Typing, but it isn't link-time resolution either. It's sort of a Schroedinger's Cat situation. Until you open the box it could be anything. The first Generics implementations and later generations of code obfuscators (ab)used the hell out of this. In fact I don't think Pizza (Java 1.1 era generics prototype) worked without it, and some languages-on-the-JVM may have been intractably slow.
- brianberns 7y agoOff topic: I’ve had success explaining the Monty Hall problem by generalizing it to, say, 10,000 doors, where Monty opens 9,998 of them before allowing you to switch. People seem to intuitively understand that it’s extremely likely that the prize is behind the other door.
- StavrosK 7y agoYou'd think that this would make it evident, but every person I've said this to said "no, you still have a 50-50 chance". I just give up after that.
- brianberns 7y agoAt that point, the only thing to do is set up 20 playing cards and offer them a prize of $100 for every $10 they wager.
- 08-15 7y ago'Dynamic typing' is to 'typing' as 'emotional intelligence' is to 'intelligence'.