Hacker News Reader

Python's type system isn't very expressive-- for example, you have "list" and "dict" types but not "list of int"

Sure you can.

  >> from array import array
  >> a = array('i')
  >> a.append(3)
  >> a
  array('i', [3])
  >> a.append('Hello')
  TypeError: an integer is required

The default "list" type just happens to be an heterogeneous list.

All of the modern dynlangs (e.g. Python, Ruby, Clojure) enforce type safety.

Well, a lot of them. Some are weakly typed, and IMO weak typing is genuinely damaging whereas I'll concede some room for the static/dynamic debate.

Example: What's "1" + 1?

Answer: In JavaScript, it's "11". In PHP, it's 2. Meaning it's possible that it could mean two different things in the same file.

That's not a weak typing artifact, its an artifact of the fact that different languages use operators with the same name but with different semantics. (And the fact that you can have PHP and JS, which are different languages, in the same file.)

You could have the same issue with languages with indisputably strong, static typing with different semantics if there was a way of embedding them in the same file.

Language that value strong type-safety guarantees won't respond to a request for "1" + 1 by quietly coercing one value to the other's type and moving along as if nothing strange happened. They'll generate a type mismatch error because adding an integer to a text string is undefined operation.

Perhaps (though, discarding the emotional language of "quietly" and "as if nothing strange happened", there's all kinds of things in strong, statically-typed languages that aren't much different structurally from that, though if they did it would usually be by way of an operator working on a typeclass which included a total, rather than partial, conversion function to support the operation, so that the semantics of addition of string and whatever numeric type it was supported with would be well defined for all strings, rather than being only defined for particular strings; then again, its not like Haskell doesn't have functions that crash on values of an appropriate type but unsuppored specific values, so maybe not), but, in any case, f a b (or f(a,b) or (f a b) or a op b, depending on the syntax of the languages involved and the kind of function/operator at issue) having two different meanings in two different languages (specifically, two that can be included in the same file), which was what was complained about that example, isn't something that only occurs with that example, and it certainly can occur in strong statically-typed languages without even considering hypothetical constructs.

"Meaning it's possible that it could mean two different things in the same file."

If you're spanning languages, that's not unusual. I have Haskell code with C in quasiquotes. What's x /= 2?

You're right. I wasn't precise and conflated those issues. Thank you.

You are far from the first. Many, many years ago, I made a more embarrassing mistake. I insisted in a job interview that OCaml was dynamically typed because it didn't require explicit typing. (To my naive eye, it "looked" like a dynlang). When I realized that I was interviewing with an expert, I backed off and admitted that I was wrong, not entirely sure why but not about to argue with someone who knew the language in depth. (And, of course, I was wrong.) I still got the job.

I'd actually argue that strong vs. weak is a continuum and somewhat subjective. One of my gripes with Scala is that the type system (as used in the field) isn't strong enough. It will implicitly auto-promote types in ways you might not want (i.e. List[Int] :+ String = List[Any]). It can be a strong type system, but the quality of programmers has a huge influence on your experience with Scala. If you have bad programmers who do things the Enterprise Java Way, you can quickly end up with compile-speed issues. But that's another rant. Scala's great for mid-sized projects or when the developers are strong.

"It will implicitly auto-promote types in ways you might not want (i.e. List[Int] :+ String = List[Any])."

Wow, that seems to totally miss the point of using types to help you catch errors.

No, because if you then try to call an Int-specific method on an item from that List[Any], you will still get a compile time error.

Silently inferring List[Any] is like a null reference. The error that you get told about is in a different place to where the problem that you need to fix is. In this case, the static type system could have been more helpful.

There have been attempts to fix this - WartRemover specifically has a Wart for any uses of Any for example.

No, a compile time error is nothing at all like a runtime null pointer exception.

Given that the language supports subtype polymorphism, this is exactly how the type inference should work. Any is the narrowest available supertype.

If you don't like it, there's a pretty simple fix: add an explicit type ascription, which you should be doing for the return values of any methods anyway.

It's like a null reference in that both increase the distance between the error and the report of failure, and both have a way of working correctly.

The distinction between compile time failure and runtime failure is an important one, but not the only thing going on.

Hehe, fun story. Totally agree with you about Scala. I'm hoping to do all future development in Haskell.

What would it help, in Python, to have 'list of int'?

A more compact representation is one advantage - that's why numpy has array of int.

You don't have to validate all objects inside of that list are an int or handle cases via duck typing, exceptions, etc.

As _yosefk said, the interpreter can assume a more compact representation.

I agree, it would be good to tighten up the terminology. "Weak typing" should be reserved for stuff where the underlying bits can get reinterpreted at will, e.g.:

    printf("%d", 42.0);

Strong typing means the type of each chunk of memory is known and can't be arbitrarily changed, and then static/dynamic refers to how much type information is present at compile time.

Might be a losing battle, though. Strong/weak has been overloaded in this way for a long time.

I'm inclined to call that "optionally typed". As in, values nominally have a static type associated with them, but it's possible (even easy) to bypass the type system.

C#, for example, is mostly strong and static. But within 'unsafe' contexts you're allowed a lot of those kinds of C-style shenanigans, and you can replicate C unions using the StructLayout and FieldOffset attributes, so the type system is ultimately optional.

I think of weak typing as a whole continuum of different things. At an extreme end you have C's level of optional typing. But there's also more tame stuff like implicit casting (which C# also has) that I'd also count as a form of weak typing.

Well, printf is a vararg function, so even what type checking C has is out of play (except for the first parameter).

C doesn't just let you reinterpret bits at will. You have to jump through one of a few very specific hoops. You have to cast, you have to use a union, or you have to use a vararg function. (Granted, those are some pretty big hoops, but my point is, you have to use one in order to reinterpret bits.)

I don't think C's type promotion rules are in the same category. You can promote a short to a double when adding it to a double, but that's not exactly "reinterpreting bits at will".

Or you can call a function without a prototype (no longer allowed in C99, thankfully), call a function whose prototype's type signature doesn't match the implementation, access a global variable whose declaration doesn't match the definition, access a struct using a different declaration than the one used by whoever put the data there in the first place, or just do an accidental type pun through a void *, which requires no casting. It's not at all hard to do by accident. Much of this is why binary compatibility for libraries written in C is so hard to achieve over the long term.

I agree that type promotion isn't the same, but I didn't mention that anyway....

Argh. I forgot that C doesn't do name mangling. Most of those problems go away in C++, though (he said hopefully, but without complete confidence...)

The problem of mismatched prototypes goes away (except for extern "C" functions, of course) but then you get fun stuff like fragile base classes. If you have a base class in a library and a subclass in an application that links against that library, you can never add a virtual function to the base class again without breaking backwards compatibility (and causing all sorts of accidental type-punning chaos when you try to call methods).

> "Weak typing" should be reserved for stuff where the underlying bits can get reinterpreted at will, e.g.:

> printf("%d", 42.0);

which does not demonstrate your point and is valid Python:

    >>> "%d" % 42.0
    '42'

also the more odd

    >>> "%.2f" % True
    '1.00'

and who could forget

    >>> "foo" * 3
    'foofoofoo'

edit: forget about this, for some reason I'd forgotten what the example would output…

Your first Python example is just numeric coercion, not weak typing. Haskell does numeric coercion too (try 2 + 1.1 in ghci). C does not behave like Python and print 42 in this example. Try it yourself and see.

True being coercible to a number is unfortunate, but it's still not the same as what C does with that printf.

"foo" * 3 is just an example of a polymorphic operator. You could implement the same in any strongly typed language that allows polymorphic operators.

Haskell doesn't do numeric conversion, it just allows numeric literals to have any valid numeric type.

If you tried it with variables you would get a type error:

    > let x = 1.0 :: Double
    > let y = 1 :: Int
    x + y
    <interactive>:10:5:
      Couldn't match expected type ‘Double’ with actual type ‘Int’
      In the second argument of ‘(+)’, namely ‘y’
      In the expression: x + y

It sometimes looks like conversion because the literal `1` is polymorphic and can have a more specific type like `Int` or `Double` inferred from context.

Ah, thanks for the correction.

(Different poster.) In fact, one of the beautiful things about Haskell is that the type system can (usually) infer exactly as much specificity as is needed.

    λ> :t 5
    5 :: Num a => a
    λ> :t 5.6
    5.6 :: Fractional a => a
    λ> :t (5 :: Integer)
    (5 :: Integer) :: Integer

The type of the literal "Num a => a" means that the literal "5" works for any type in the Num typeclass. So you can mix literals with any numeric type because the compiler will correctly infer the right type. You can even get usages like this:

    λ> :t (\x -> x + 5)
    (\x -> x + 5) :: Num a => a -> a
    λ> let f = (\x -> x + 5) in (f (0 :: Int), f (0 :: Double))
    (5,5.0)

> True being coercible to a number is unfortunate

If we want to be really pedantic, in Python 2.X, True isn't coercible to an integer, it is an integer.

>>> True == 1 True >>> isinstance(True, int) True

This is an artifact of the fact that when Python was first created, it didn't have boolean types, so when they were added later, "True" and "False" were bolted on as aliases to the integers 1 and 0.

I think it was meant to be C, where it would often (although not always - very much implementation defined) wind up interpreting the bits of the float as if they represented an integer.

That's a C example, where it demonstrates my point perfectly. Python doesn't even have a printf function, where did you get the idea it was supposed to be Python?

> That's a C example, where it demonstrates my point perfectly.

Yeah I kinda forgot about the result.

> Python doesn't even have a printf function, where did you get the idea it was supposed to be Python?

Nowhere? I never assumed your example was python, I was showing something irrelevant.

When you quoted my printf statement and followed it with "which does not demonstrate your point and is valid Python" that kind of implied you thought it a) doesn't demonstrate my point and b) is valid Python.

If that's not what you mean, that was not at all evident.

> If that's not what you mean

It's not, I pretty much fell into the issue you decry at the end of your comment: I considered the operation being allowed at all (by the compiler and the runtime) not being evidence of weak typing. Which I guess is technically correct, but is mostly completely irrelevant to the point you were making.

If someone is saying something bad about a language and it has something to do with types being weak, they must be saying it about Python?