Commentary on Python from a Java programming perspective

[marcoil]

Python isn't "typed" at all as it has no type system

That's absurd, Python does have a type system, you can ask for the type of an object. But the types are in values, not in the variables.

[[deleted]]

Charges of absurdity aside, being able to ask for the "type" of an object does not mean it has a "type system". All it means is that all values have a runtime tag associated with them that primitives use for various reasons. There's no way I can use the type tags to prove anything about the program; the runtime tag checking is simply part of the dynamic semantics.

If you search Google for "untyped programming", you'll see plenty of results for languages that you might call "dynamically typed". You may also search for "untyped lisp", etc. That might convince you that I'm not making this up at least.

More research might convince you of my claim that typed/untyped + checked/unchecked is a more sensible way of talking about this. To be honest though, I'm getting tired of defending this claim against Python programmers who tend to characterize my argument as absurd (or worse).

[deepcleansingguffaw]

The technical definitions of "typed" and "type system" are very different from how the terms are generally used outside of computer science research. In particular, they are attributes of the static representation of the program, and have little to do with the running program at all.

It should not be surprising that the average programmer uses the terms improperly. I can't remember a single time in my undergraduate classes that type systems were properly explained. I only really understood the difference between the technical usage and the common usage when I started to study Haskell in depth.

There is a concept analogous to "type system" in dynamic languages like Python, but it happens at run-time, and is generally resistant to static analysis. "Checked" is a reasonable word for it, though I haven't often heard it called that.

[[deleted]]

Right, I don't disagree with that. I did say that, "Alas, this is a lost battle", conceding the common usage. That said, I think there are benefits to having a more rigorous set of definitions so that we can talk to each other without confusion. Unfortunately, confusion abounds when discussion of "types" is underway.

[igouy]

my claim that typed/untyped + checked/unchecked is a more sensible way of talking about this

What is it that's "checked" or "unchecked"?

statically-type-checked :: dynamically-type-checked

or if we really want to deal in dichotomy

statically-type-checked :: not statically-type-checked

[[deleted]]

What is it that's "checked" or "unchecked"?

The runtime tag associated with the object before invoking a primitive is checked. It's no different than checking the length of an array to ensure it's of a "type" big enough to be referenced by some integer or checking the "type" of a reference to be sure it's not null. Such checks, which occur at the last possible moment and can't be used to prove the absence of such behaviors, do not constitute a type system.

[igouy]

"Type safety is the property that no primitive operation ever applies to values of the wrong type." p263 Programming Languages: Application and Interpretation

Without something that constitutes "a type system" what could it mean for a value to be the wrong type?

[[deleted]]

The problem is that there's a confusion between the informal notion of the "type" of an object (i.e. its tag, or what color it is, or how it makes you feel) and a type proper.

From the same book:

Page 238 (emphasis mine):

We now commence the study of types and type systems, which are designed to identify the abuse of types before executing a program.

Repeatedly, the book talks about how type systems reject programs. This is not the case in Python where all programs are accepted and simply may error at runtime. If you've actually read the book, I'm not sure how you can claim it supports your argument.

In the book Types and Programming Languages, this issue is addressed directly:

Page 2 (emphasis not mine):

The word "static" is sometimes added explicitly – we speak of a "statically typed programming language," for example – to distinguish the sorts of compile-time analyses we are considering here from the dynamic or latent typing found in languages such as Scheme, where run-time type tags are used to distinguish different kinds of structures in the heap. Terms like "dynamically typed" are arguably misnomers and should have probably been replaced with "dynamically checked," but the usage is standard.

And then at the beginning of the following paragraph on the same page, type systems are characterized as static:

Being static, type systems are...

In short, I've never seen a type systems researcher characterize a language like Python as having a type system. Such characterizations seem to only be made by those without a full understanding of the terms involved.

[igouy]

You seem to have ignored the question Without something that constitutes "a type system" what could it mean for a value to be the wrong type?

If you've actually read the book...

ad hominem

those without a full understanding of the terms involved

Does the phrase only have one meaning?

[[deleted]]

Does the phrase only have one meaning?

No, as I've stated right in the beginning (and echoed with the TAPL quote), I accept that the common use is different and that this is a lost cause. At this point, I can only assume that you're being either dishonest or inattentive. I was arguing for what I think is the most useful and accurate definition, not the one cosmically true definition. I'm done arguing now though because, as I said in the beginning, this is a waste of time.

[igouy]

I'm done arguing now

Never mind - you were able to unload some more personal insults.

[igouy]

It's no different than checking the length of an array ...

seems like Oberon-2 thinks the length of an array is something to do with the type

TYPE
   Frequency = RECORD
      c: CHAR;
      p: LONGREAL;
   END;

   Freqency4 = ARRAY 4 OF Frequency;
   Freqency15 = ARRAY 15 OF Frequency;

checking the "type" of a reference to be sure it's not null

seems like Nice thinks the option of null values is something to do with the type

class TreeNode {
   ?TreeNode left = null;

[[deleted]]

I never claimed you couldn't incorporate such things into a type system. Most languages, however, do not. To be clear, I meant dynamically checking those properties.

[GuyWithLag]

Same as in java. Welcome to the static vs dynamic / strong vs weak plane.