Hacker News Reader

Comment by aapycgarb | Hacker News Reader

Python's type system is weak whether they self-identify that way or not. Types are implicitly converted in a variety of cases, notably True-ness. Meanwhile, runtime type identity is kind of meaningless; classes and individual objects can have their behavior meaningfully changed at runtime. The most you can say about any variable in Python is that it is a descendant of 'object' or else some primitive type.

View on HN

If Python's `if` is weakly typed, then Rust's `for` and `.` are weakly typed. Few would say that, though.

One place where Python is pretty weakly typed is going the other way, where it accepts things like: true + true * 2 - false / true, even outside of if statements.

I've definitely been bitten by this before, accidentally passing in a book parameter instead of an int, and having some math work initially and then blow up months later.

Knuth argues against this kind of implicit bool to integer conversion in Concrete Mathematics.

Nitpick: this isn't an implicit conversion.

There's a lot of history of languages without a real boolean type using integer 0 and 1 as the sentinel values indicating false-ness and true-ness.

And Python, in a nod to that, implements bool as a subclass of int, of which only two instances can ever exist (with False having a value of 0 and True having a value of 1).

So this isn't weak typing -- isinstance(True, int) is True in Python, and operations like the ones you're mentioning work because of that, for the same reason any other subclass of int would work.

Interesting, so technically isn't weak typing, but in practice to me it is a distinction without a difference. You could make int a subtype of string, and allow things like "1" + 1 == "11" and end up with many of the same problems of weakly typed languages.

Well, there's also ancient-history stuff going on here in that Python originally didn't have a boolean type, which mean using integer 0 and 1 was the standard practice. "True" and "False" as aliases for integer 1 and 0 were added in 2002, and the actual boolean type -- implemented as a subclass of int since that got automatic compatibility with existing code using integer values -- was added in 2003.

Well, that would violate the Liskov Substitution Principle.

But I think there's a fundamental divide about what weak typing actually is. For example, it's entirely possible in Rust to have implemented Add for i32 and String. Even this isn't weak typing in its traditional form.

AFAIK, in this sense weak typing refers to whenever the compiler will implicitly cast one type to another in order to satisfy a type constraint. C's number types do this. PHP does this on everything. Javascript has, eg., [] + [] == "". Python does not do this - all type casts are explicit in the implementation of the operator or function (which is implemented on the type, not globally).

It's reasonable to argue that the use of the phrase "weak typing" to mean "things I don't like about a type-system" is not only well established but maybe even more useful. It does, however, irritate Python programmers who don't want their language lumped in with PHP.

It is so because in the beginning python didn't have a boolean type. It used 0 and 1 integers instead. Later when bool was introduced it was a subclass of integers.

Wish they dropped it in the move to 3

Everything in Python is an object:

    >>> isinstance(type, object)
    true
    >>> T = type('T', (), {})
    >>> isinstance(T, type)
    True
    >>> isinstance(T, object)
    True
    >>> isinstance(T(), object)
    True
    >>> isinstance(int, object)
    True
    >>> issubclass(int, object)
    True
    >>> isinstance(1, object)
    True

Types are implicitly converted in a variety of cases, notably True-ness

First off, see my other comment about Python's boolean type and the fact that it is an integral type:

https://news.ycombinator.com/item?id=9595988

Second, boolean evaluation of arbitrary types in Python is not "weak" -- it's well-defined through a standard language-level protocol, and it's always very clear what can and can't be evaluated as a boolean and what boolean values will result from doing so.

I think you should brush up a little on your python-bashing methodology. It might work on individuals that don't know enough about Python, but not for the rest of us.

Reply on news.ycombinator.com