Re:Python 3 Types in the Wild: A Tale of Two Type Systems [pdf]
by solumos on Wednesday April 14, 2021 @11:42PM
(#26815982)
I 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.
[ Parent
| on HN ]
Re:Python 3 Types in the Wild: A Tale of Two Type Systems [pdf]
by pmontra on Thursday April 15, 2021 @02:28AM
(#26816777)
I 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.
Re:Python 3 Types in the Wild: A Tale of Two Type Systems [pdf]
by exdsq on Thursday April 15, 2021 @03:09AM
(#26817040)
“Untyped” is the phrase used in literature too
https://www.sciencedirect.com/science/article/pii/S147466701...
Practically, untyped languages would include asm and forth.
Re:Python 3 Types in the Wild: A Tale of Two Type Systems [pdf]
by kstrauser on Thursday April 15, 2021 @01:27AM
(#26816457)
In Python, objects have types. Variables are best thought of as void* pointers to objects.
Re:Python 3 Types in the Wild: A Tale of Two Type Systems [pdf]
by dr_zoidberg on Thursday April 15, 2021 @09:49AM
(#26820470)
I'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".
Re:Python 3 Types in the Wild: A Tale of Two Type Systems [pdf]
by Spivak on Thursday April 15, 2021 @10:27AM
(#26820910)
Pointers that also carry the underlying type information.
Re:Python 3 Types in the Wild: A Tale of Two Type Systems [pdf]
by kstrauser on Thursday April 15, 2021 @10:55AM
(#26821233)
I 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.
Re:Python 3 Types in the Wild: A Tale of Two Type Systems [pdf]
by Spivak on Thursday April 15, 2021 @11:59AM
(#26822121)
I 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.
Re:Python 3 Types in the Wild: A Tale of Two Type Systems [pdf]
by kstrauser on Thursday April 15, 2021 @02:16PM
(#26824203)
Ah, 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.
Re:Python 3 Types in the Wild: A Tale of Two Type Systems [pdf]
by guram11 on Thursday April 15, 2021 @02:12AM
(#26816681)
iirc 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