13 ms·

Strongly agree with author. I really like Python and at one point thought that it makes sense to write almost any project in it, since it's so versatile and I k

Strongly agree with author. I really like Python and at one point thought that it makes sense to write almost any project in it, since it's so versatile and I know it pretty well. After working on a quite large application and having to use lots of assert(isinstance(arg, type) at the beginning of almost every function, I began to think that a strong type system is very much needed for large projects. I believe this was one of the reasons why Twitter moved from Ruby to Scala. I still love to use Python for hacking something quick for myself. But I also look at some popular strongly-typed languages now and hope to get better at one of them soon.

ris 7y ago
You're confusing static typing with strong typing. Python is strongly-typed, but not statically typed. Python's optional typing could also be used to get rid of a lot of your assertions.
- yawaramin 7y ago
  You are confusing optional typing with optional static typechecking. Python has the latter, not the former. In other words, everything is typed in Python and it will always check types at runtime.
jsjohnst 7y ago
> I began to think that a strong type system You’re confusing static/dynamic and strong/weak. Python is a strongly typed language, but also is dynamicly typed language. Need proof? Try doing this: a = 3 b = “3” c = a + b > having to use lots of assert(isinstance(arg, type)) Python has type hinting now, try using a current version of Python and this isn’t needed.
- flyinglizard 7y ago
  The point is that your example will not break anything until run time, unless some static analysis tools are deployed (which are much more limited compared to what a compiler can achieve).
- bill1124 7y ago
  strong type system != strongly typed. Type hinting does not guarantee to catch everything, but for Python proponents 95% is apparently "good enough".
- mjw1007 7y ago
  I think that example shows that Python's type system isn't the weakest out there, but it's still pretty weak. For example, it doesn't have a built-in way to make a dictionary-whose-keys-must-be-integers (so with your example above if you wrote thedictionary.get(b) rather than thedictionary.get(a) you'd get an error rather than None). I've often seen learners have trouble with this sort of thing (you read a number from a file, neglect to call int(), and get mysterious lookup failures).
  - UncleEntity 7y ago
    > so with your example above if you wrote thedictionary.get(b) rather than thedictionary.get(a) you'd get an error rather than None Technically, dict.get() returns None if the item isn't found and you don't provide a different value for its default. thedictionary[b] would throw a KeyError on the other hand. One could always subclass dict if they wanted to ensure the keys were always integers or whatever. > I've often seen learners have trouble with this sort of thing (you read a number from a file, neglect to call int(), and get mysterious lookup failures). Not sure if you're arguing for a stronger type system or having the language promote the string to an int as (I've heard) other scripting languages do. Though, once you figure out the language doesn't automagically parse files for you you're well on the way to finding more fun and exciting ways to get python to throw error messages at you.
- LawnboyMax 7y ago
  I am using the current Python version and tried type hinting. I don't see how it can help much, since types are not enforced;especially when interfacing with not-so-well-tested modules that don't use type hinting and can sometimes return values of unexpected type. It's definitely a neat feature when writing an application from scratch that interfaces with few other modules or only the well-tested ones.
joshvm 7y ago
> assert(isinstance(arg, type)) The most irritating thing I've found is trying to write a function that accepts either a path or the raw contents of a file. Python 3 makes this easy, you can check against string. Python 2 of course treats everything as a byte string. In the end I just check the length of the input if the interpret identifies as python 2. If it's a short byte string, I assume it's a file name. Otherwise the minimum expected file size is almost certainly larger than the maximum path length.
- newen 7y ago
  Why would you ever do that? Why would you even want a function that accepts either a file name or file contents when both are strings? What's so hard about defining a new function?
  - mjw1007 7y ago
    One common case where this is attractive is where you have a bunch of "public" functions built on top of each other, with the higher ones passing that parameter on and not otherwise caring what it is: high_level_function(src, ...) ... mid_level_function(src, ...) ... mid_level_function(src, ...) low_level_function(src, ...) ... low_level_function(src, ...) ... If you can make the low-level function generic one way or another, you avoid having to duplicate the higher-level functions. Another case is where there are two or more parameters that you want to be generic in this sense: if your only option is duplicating the function you can end up having to define inconveniently many variants.
    - newen 7y ago
      Yeah, that is convenient and I do that often. But I try to wrap the variables in different types depending on their source (e.g. whether it's a filename or file content) so that functions further down can disambiguate between variables explicitly.
  - guidopallemans 7y ago
    An example: pandas.read_csv https://pandas.pydata.org/pandas-docs/stable/reference/api/pandas.read_csv.html https://pandas.pydata.org/pandas-docs/stable/reference/api/p...
vonseel 7y ago
> having to use lots of assert(isinstance(arg, type) at the beginning of almost every function Python should not be written like this; assertions can be ignored at runtime: https://docs.python.org/3/using/cmdline.html#cmdoption-o https://docs.python.org/3/using/cmdline.html#cmdoption-o A much better solution is to use qualified try/except blocks to handle potential errors.

ris 7y ago

You're confusing static typing with strong typing. Python is strongly-typed, but not statically typed. Python's optional typing could also be used to get rid of a lot of your assertions.

yawaramin 7y ago
You are confusing optional typing with optional static typechecking. Python has the latter, not the former. In other words, everything is typed in Python and it will always check types at runtime.

jsjohnst 7y ago

> I began to think that a strong type system You’re confusing static/dynamic and strong/weak. Python is a strongly typed language, but also is dynamicly typed language. Need proof? Try doing this: a = 3 b = “3” c = a + b > having to use lots of assert(isinstance(arg, type)) Python has type hinting now, try using a current version of Python and this isn’t needed.

flyinglizard 7y ago
The point is that your example will not break anything until run time, unless some static analysis tools are deployed (which are much more limited compared to what a compiler can achieve).
bill1124 7y ago
strong type system != strongly typed. Type hinting does not guarantee to catch everything, but for Python proponents 95% is apparently "good enough".
mjw1007 7y ago
I think that example shows that Python's type system isn't the weakest out there, but it's still pretty weak. For example, it doesn't have a built-in way to make a dictionary-whose-keys-must-be-integers (so with your example above if you wrote thedictionary.get(b) rather than thedictionary.get(a) you'd get an error rather than None). I've often seen learners have trouble with this sort of thing (you read a number from a file, neglect to call int(), and get mysterious lookup failures).
- UncleEntity 7y ago
  > so with your example above if you wrote thedictionary.get(b) rather than thedictionary.get(a) you'd get an error rather than None Technically, dict.get() returns None if the item isn't found and you don't provide a different value for its default. thedictionary[b] would throw a KeyError on the other hand. One could always subclass dict if they wanted to ensure the keys were always integers or whatever. > I've often seen learners have trouble with this sort of thing (you read a number from a file, neglect to call int(), and get mysterious lookup failures). Not sure if you're arguing for a stronger type system or having the language promote the string to an int as (I've heard) other scripting languages do. Though, once you figure out the language doesn't automagically parse files for you you're well on the way to finding more fun and exciting ways to get python to throw error messages at you.
LawnboyMax 7y ago
I am using the current Python version and tried type hinting. I don't see how it can help much, since types are not enforced;especially when interfacing with not-so-well-tested modules that don't use type hinting and can sometimes return values of unexpected type. It's definitely a neat feature when writing an application from scratch that interfaces with few other modules or only the well-tested ones.

joshvm 7y ago

> assert(isinstance(arg, type)) The most irritating thing I've found is trying to write a function that accepts either a path or the raw contents of a file. Python 3 makes this easy, you can check against string. Python 2 of course treats everything as a byte string. In the end I just check the length of the input if the interpret identifies as python 2. If it's a short byte string, I assume it's a file name. Otherwise the minimum expected file size is almost certainly larger than the maximum path length.

newen 7y ago
Why would you ever do that? Why would you even want a function that accepts either a file name or file contents when both are strings? What's so hard about defining a new function?
- mjw1007 7y ago
  One common case where this is attractive is where you have a bunch of "public" functions built on top of each other, with the higher ones passing that parameter on and not otherwise caring what it is: high_level_function(src, ...) ... mid_level_function(src, ...) ... mid_level_function(src, ...) low_level_function(src, ...) ... low_level_function(src, ...) ... If you can make the low-level function generic one way or another, you avoid having to duplicate the higher-level functions. Another case is where there are two or more parameters that you want to be generic in this sense: if your only option is duplicating the function you can end up having to define inconveniently many variants.
  - newen 7y ago
    Yeah, that is convenient and I do that often. But I try to wrap the variables in different types depending on their source (e.g. whether it's a filename or file content) so that functions further down can disambiguate between variables explicitly.
- guidopallemans 7y ago
  An example: pandas.read_csv https://pandas.pydata.org/pandas-docs/stable/reference/api/pandas.read_csv.html https://pandas.pydata.org/pandas-docs/stable/reference/api/p...

vonseel 7y ago

> having to use lots of assert(isinstance(arg, type) at the beginning of almost every function Python should not be written like this; assertions can be ignored at runtime: https://docs.python.org/3/using/cmdline.html#cmdoption-o https://docs.python.org/3/using/cmdline.html#cmdoption-o A much better solution is to use qualified try/except blocks to handle potential errors.