Comment by syndicatedjelly | Hacker News Reader

Comment by syndicatedjelly | Hacker News Reader

Parent Full thread

syndicatedjelly

Python is not a scripting language, it's a weakly-typed general-purpose programming language. I too dislike the lack of strong-typing, but there are dozens of good options if that's what I need in a codebase.

It sounds like your problem is with people who write Python, not Python itself. Not every person who writes code has the time or ability to learn all the nuances of strongly-typed functional languages. In my opinion, people outside of software engineering shouldn't bother with such esoteric domain knowledge. "Real" programmers like yourself are there for that reason - to rewrite their prototyped code in whatever style you see fit.

Complaining that they don't know how to program is a great way to alienate smart people in other domains. Knowledge of computer science tends to blow up people's egos in a way that I have observed in few other fields.

Python’s strongly, dynamically typed. Try adding “12”+3 and it will throw a TypeError at you.

That only works with a few built in types, like numbers. For any other type, you had better hope that the author has added such checks.

This isn't true, even if you define your own types/classes you still can't add them together willy nilly unless you (or a superclass) explicitly defined an addition operator. The Python language itself will never implicitly coerce a type for you, not even for floating point and integer addition. [0]

[0] https://www.pythonmorsels.com/type-coercion/

You're right. Classes don't even provide such operators by default:

  >>> class Foo:
  ...     ...
  ...
  >>> class Bar:
  ...     ...
  ...
  >>> a = Foo()
  >>> b = Bar()
  >>> a+b
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: unsupported operand type(s) for +: 'Foo' and 'Bar'

If anything, the complaint is that pre-type-hinted Python was too quick to raise a TypeError without helping you know what types it was expecting. The only case I can think of where it was too lenient was where Python 2 conflated strings and bytes. That change was 90% of the pain of the Python 3 upgrade, and now they're different types.

I was speaking generally not specifically about addition. If you create new types and especially new operations on those types, then it will be up to you to add runtime "type checks" to avoid other failures. Try defining equality for a Point class for an example.

Reply on news.ycombinator.com