7 ms·
Someone who needs types could just write in a strongly-typed language.
by xvilka 6y ago
Someone who needs types could just write in a strongly-typed language.
- seanmclo 6y agoUnfortunately, this isn’t always an option if you need to use a library that’s only available in Python.
- xvilka 6y agoIt's possible to use it in a Julia-like fashion (like PyCall.jl[1]). For example, with OCaml one could use Pyml[2]. [1] https://github.com/JuliaPy/PyCall.jl https://github.com/JuliaPy/PyCall.jl [2] https://github.com/thierry-martinez/pyml https://github.com/thierry-martinez/pyml
- dr_zoidberg 6y agoPython is strongly typed. It's also dynamically typed. They are not contradictory between each other.
- solumos 6y agoI once had someone try to tell me that python was "untyped" - I guess people assume a lot when they come from a first-class statically-typed language.
- kstrauser 6y agoIn Python, objects have types. Variables are best thought of as void* pointers to objects.
- dr_zoidberg 6y agoI've found over the years that people have an easier time understanding how Python manages variables when you tell them that, rather than "in-memory boxes with data" as is the case in other languages, Python variables are more like "name tags that you attach to an object".
- Spivak 6y agoPointers that also carry the underlying type information.
- kstrauser 6y agoI don’t remember what the CPython implementation looks like, but even if the information is there, it’s not really exposed to end users. “type(foo)” doesn’t return the type of the name “foo”, but of the object that “foo” points to.
- Spivak 6y agoI meant that it's a pointer that is aware of the type of object it's pointing to by virtue of all objects knowing their own type. Same difference I guess. Unlike void pointers or Object references in Java you can't "forget" an object's type.
- kstrauser 6y agoAh, I think I see what you mean. I still think it's more accurate to say that names are just pointers that don't have any typing info themselves (or if they do, it's an implementation detail that doesn't actually get surfaced and isn't a part of the language definition). In Python it doesn't quite make sense to talk about the type of a "name" or "variable" or "pointer" because, because it points to an object, and that's where the canonical type info actually lives.
- guram11 6y agoiirc untyped is not incorrect, untyped lambda calculus for instance is where your value type is unknown until your runtime like dynamic type, untyped doesn't mean you don't have type in your language
- pmontra 6y agoI wonder if my professor of the Programming Languages course at university would laugh or cry at such a definition. I expect that everybody doing this job has a CS or equivalent degree and knows the difference between strong / weak and static / dynamic typing. Reading other comments here demonstrates this is not the case. This is not a bad thing (luckily we only need a screen and a keyboard) but hopefully they'll have learned something new today. Btw, there is a lot I don't know despite my degree. No hard feelings.
- exdsq 6y ago“Untyped” is the phrase used in literature too https://www.sciencedirect.com/science/article/pii/S1474667016339969 https://www.sciencedirect.com/science/article/pii/S147466701... Practically, untyped languages would include asm and forth.
- cbarrick 6y agoMy ELI5 for this has always been that static vs dynamic concerns variables; strong vs weak concerns objects. - Static + Weak = C - Static + Strong = Haskell - Dynamic + Strong = Python - Dynamic + Weak = JS
- cjfd 6y agoIt is strongly typed in the sense that 3 + "5" is an error. It also has duck typing which is weak. So, which is it? I would say it is more weak than strong.
- NoThisIsMe 6y agoThere are two axes: strong/weak and dynamic/static. Examples: Python: strong, dynamic PHP: weak, dynamic C: weak, static Haskell: strong, static
- zo1 6y agoDuck-typing doesn't imply weak typing, but rather dynamic typing. Can you explain why you consider dock-typing as being weak-typing?
- lmm 6y agoThere's no such thing as "dynamic types". A type is by definition associated with an expression in a language, but those expressions are part of the program's static source code. Python has some kind of checking of the runtime values involved in certain operations, but that's not typing.
- HelloNurse 6y agoTypes are not associated with expressions in Python: evaluating an expression produces a typed value, whose type, and not only its value, depends on the type and/or values of the inputs. Example: def comparativeInsult(a,b): if b>a: return "try again" if a>b: return a/b else: return None The type is, for all practical purposes, a part of the value of a Python object.
- lmm 6y agoSuch a thing is not a type. Not by the usual definition, which predates not only python but mechanical computation.
- benrbray 6y agoEveryone needs types. Here's one of my favorite quotes: > "Dynamic typing" The belief that you can't explain to a computer why your code works, but you can keep track of it all in your head. — Chris Martin (https://chris-martin.org/2015/dynamic-typing https://chris-martin.org/2015/dynamic-typing)
- pdonis 6y ago> Here's one of my favorite quotes Here's my response to that quote: "Static typing": The belief that if your code type-checks correctly, it will do exactly what you intended. (A variant of the belief that if your code compiles correctly, it will do exactly what you intended.) Of course, taken literally, that's unfair, but so is the quote you gave. Everything you add to your code has a cost. Time you spend writing type specifications is time you're not spending doing something else that might add more value. Sometimes writing type specifications is the best use you can make of that time; sometimes it isn't. Python at least gives you both options: use type annotations if you want, but you don't have to if you don't want to.
- IgorPartola 6y agoThis. Can also be applied to unit testing: the belief that if your code passes its unit tests, it will do exactly what you intend. I see way too many code bases that test things that are easy and xfail things that are hard because it turns out that you can’t just test your way to a complex product, but you sure can make yourself feel good by testing the fact that a dict acts like a dict.
- benrbray 6y agoI see your point, but I do think the amount of time spent writing type specifications is (usually) negligible, in return for an extremely large benefit whenever the code needs to be read by you or someone else later. I would certainly argue that anyone who writes a library, whose public API will be consumed by hundreds or thousands of people, should always include type annotations. After working in a TypeScript codebase for so long, it's jarring to return to Python or even vanilla JavaScript where I no longer have breadcrumbs to help me keep track of how the code is organized. Python's type annotations leave something to be desired, in terms of how easy they are to include in code and how well the tooling supports them. I'd almost rather see something like "Typethon" with better syntax+soundness that compiles-to-Python. Types are an optional tool, sure, but they're one of the most valuable tools we have to catch (not eliminate entirely) bugs and hasten development (without introducing errors).
- deleted 6y ago[deleted]
- coldtea 6y agoOnly if they don't also need X other things that Python provides and the other language doesn't...