4 ms·

For what it's worth, Python is a strongly typed language[0] and is what the manual calls "multi-paradigm," i.e. you can write purely functionally in it[1] all y

For what it's worth, Python is a strongly typed language[0] and is what the manual calls "multi-paradigm," i.e. you can write purely functionally in it[1] all you want, though it is a fair point to observe that the community, PEPs, Guido et. al. do not encourage it, and the language implementations are probably not optimized for it. [0]: https://stackoverflow.com/questions/11328920/is-python-strongly-typed https://stackoverflow.com/questions/11328920/is-python-stron... [1]: https://docs.python.org/3/howto/functional.html https://docs.python.org/3/howto/functional.html

syllogism 7y ago
I mean...Come on, it's not like that's news to me :p. The mypy stuff in particular is somewhat promising, but it's a pretty awkward retrofit. A lot of the key APIs (e.g. numpy) were not designed around type declarations, so numpy will very often return either a float or an array depending on the input operations, keyword arguments, etc. This sort of thing is super common.
- dllthomas 7y ago
  > numpy will very often return either a float or an array depending on the input operations, keyword arguments, etc That makes it harder to find good types, but it doesn't rule it out. Either you can tell what the shape of the output should be without calling the function in question or you can't. If you can't, you should be checking the shape of the output after the call, and the type of the output should be some kind of union so the type system encourages this. On the other hand, if you can look at the arguments and easily know how the output should look, there's a fair chance you can push this knowledge into the type system. I've done similar things in flow. As a recent example, the download function in the google storage API returns a promise of the file's contents, unless the argument contains a 'destination' key in which case it returns a promise of void. Describing that as the intersection of the two function types got me the checking I want. Amusingly, I don't think there's a way to write a function with this type without a cast through any, but that's not a problem for describing an untyped API. All of that said, I don't know how well this works out with numpy and mypy in particular.
- johnfactorial 7y ago
  I just love the Hacker News guideline that comments get more thoughtful and substantive as a topic gets more divisive, I think we all benefit a lot from that aspect of this site. Honestly I only posted my comment to stir deeper public discussion on the topic, while trying to be clear at the end that it's possible but I certainly don't think it's encouraged or any fun at all. I figured it wasn't news to you, but thought the topic worth opening, perhaps news to someone else. Cheers.
Scarbutt 7y ago
you can write purely functionally in it[1] all you want Sure, but it's cumbersome.
DonaldPShimoda 7y ago
> Python is a strongly typed language In some sense, sure. But it's not statically typed, which is (in my opinion) much more important. Reasoning about function composition in Haskell is straightforward because you just have to make the types line up correctly. Technically this is true in Python, but you don't have any mechanism (by default) to check whether your implementation is correct other than writing enough tests. Yes, you can use type hints and an external type checker, but that's still not a great solution compared to any statically styped language. > you can write purely functionally in it all you want Except that Python does not optimize tail calls, which means that implementing a simple recursive solution to a problem requires reasoning about the stack (which it shouldn't, if we're doing things functionally). There are hacks to optimize for some tail calls via decorators and explicitly checking the stack, but this decreases runtime performance and does not work for things like mutual tail call recursion (which is optimized in functional-first languages). To me, lack of TCO is a huge dealbreaker. I mean I still write my Python code semi-functionally because I find FP easier to reason about, but it's more work than doing it in Haskell. And don't even get me started on the lack of support for features like algebraic data types, pattern matching, etc. --- I love Python; it's my most-used language by far, I think. And I love functional programming. And I even try to write my Python code in a functional style! But Python is not what I would call a "good" language for functional programming.
- j88439h84 7y ago
  > Yes, you can use type hints and an external type checker, but that's still not a great solution compared to any statically styped language. Why not?
  - DonaldPShimoda 7y ago
    Well it isn't built-in, so that's an obstacle to its use right there. You also have to rely on two sets of developers to ensure you can stay up-to-date, and this introduces more potential for errors and bugs. Furthermore, the static type systems supported by, e.g., MyPy do not perfectly reflect the dynamic semantics of the Python language. So what you really have is some subset of Python that you're allowed to use fully. (This is probably not a big issue for many people, to be fair.) Another problem is that systems like MyPy require you to actually write the type hints in a lot of places. Manifest type systems are not favored because requiring users to write more is almost never something they're happy with. One of the most common complaints about Java is that you have to write so many types everywhere, and while you don't need that many in statically typing your Python code, you do need quite a few. A statically typed language with good type inference definitely wins here. Type hints are also not very expressive because they're purely nominal, but Python's type system is actually structural (which is true for most dynamically typed languages, as far as I know). I haven't experimented with this too much because I don't use a type checker like MyPy, but I seem to remember that it treated types nominally. (I think I've also seen some indication that they're working to extend type hints to support structural types, but last I checked it wasn't right around the corner or anything.) What I'm getting at here is that while external type checkers like MyPy can be considered an improvement over the dynamically typed language itself, they come with a lot of caveats that make me uncomfortable. There are few cases where I truly prefer dynamic types to static ones.
pacala 7y ago
'you can write purely functionally in Python'. I wish https://github.com/tobgu/pyrsistent https://github.com/tobgu/pyrsistent were more mainstream in the Python community and get some syntax love.

syllogism 7y ago

I mean...Come on, it's not like that's news to me :p. The mypy stuff in particular is somewhat promising, but it's a pretty awkward retrofit. A lot of the key APIs (e.g. numpy) were not designed around type declarations, so numpy will very often return either a float or an array depending on the input operations, keyword arguments, etc. This sort of thing is super common.

dllthomas 7y ago
> numpy will very often return either a float or an array depending on the input operations, keyword arguments, etc That makes it harder to find good types, but it doesn't rule it out. Either you can tell what the shape of the output should be without calling the function in question or you can't. If you can't, you should be checking the shape of the output after the call, and the type of the output should be some kind of union so the type system encourages this. On the other hand, if you can look at the arguments and easily know how the output should look, there's a fair chance you can push this knowledge into the type system. I've done similar things in flow. As a recent example, the download function in the google storage API returns a promise of the file's contents, unless the argument contains a 'destination' key in which case it returns a promise of void. Describing that as the intersection of the two function types got me the checking I want. Amusingly, I don't think there's a way to write a function with this type without a cast through any, but that's not a problem for describing an untyped API. All of that said, I don't know how well this works out with numpy and mypy in particular.
johnfactorial 7y ago
I just love the Hacker News guideline that comments get more thoughtful and substantive as a topic gets more divisive, I think we all benefit a lot from that aspect of this site. Honestly I only posted my comment to stir deeper public discussion on the topic, while trying to be clear at the end that it's possible but I certainly don't think it's encouraged or any fun at all. I figured it wasn't news to you, but thought the topic worth opening, perhaps news to someone else. Cheers.

Scarbutt 7y ago

you can write purely functionally in it[1] all you want Sure, but it's cumbersome.

DonaldPShimoda 7y ago

> Python is a strongly typed language In some sense, sure. But it's not statically typed, which is (in my opinion) much more important. Reasoning about function composition in Haskell is straightforward because you just have to make the types line up correctly. Technically this is true in Python, but you don't have any mechanism (by default) to check whether your implementation is correct other than writing enough tests. Yes, you can use type hints and an external type checker, but that's still not a great solution compared to any statically styped language. > you can write purely functionally in it all you want Except that Python does not optimize tail calls, which means that implementing a simple recursive solution to a problem requires reasoning about the stack (which it shouldn't, if we're doing things functionally). There are hacks to optimize for some tail calls via decorators and explicitly checking the stack, but this decreases runtime performance and does not work for things like mutual tail call recursion (which is optimized in functional-first languages). To me, lack of TCO is a huge dealbreaker. I mean I still write my Python code semi-functionally because I find FP easier to reason about, but it's more work than doing it in Haskell. And don't even get me started on the lack of support for features like algebraic data types, pattern matching, etc. --- I love Python; it's my most-used language by far, I think. And I love functional programming. And I even try to write my Python code in a functional style! But Python is not what I would call a "good" language for functional programming.

j88439h84 7y ago
> Yes, you can use type hints and an external type checker, but that's still not a great solution compared to any statically styped language. Why not?
- DonaldPShimoda 7y ago
  Well it isn't built-in, so that's an obstacle to its use right there. You also have to rely on two sets of developers to ensure you can stay up-to-date, and this introduces more potential for errors and bugs. Furthermore, the static type systems supported by, e.g., MyPy do not perfectly reflect the dynamic semantics of the Python language. So what you really have is some subset of Python that you're allowed to use fully. (This is probably not a big issue for many people, to be fair.) Another problem is that systems like MyPy require you to actually write the type hints in a lot of places. Manifest type systems are not favored because requiring users to write more is almost never something they're happy with. One of the most common complaints about Java is that you have to write so many types everywhere, and while you don't need that many in statically typing your Python code, you do need quite a few. A statically typed language with good type inference definitely wins here. Type hints are also not very expressive because they're purely nominal, but Python's type system is actually structural (which is true for most dynamically typed languages, as far as I know). I haven't experimented with this too much because I don't use a type checker like MyPy, but I seem to remember that it treated types nominally. (I think I've also seen some indication that they're working to extend type hints to support structural types, but last I checked it wasn't right around the corner or anything.) What I'm getting at here is that while external type checkers like MyPy can be considered an improvement over the dynamically typed language itself, they come with a lot of caveats that make me uncomfortable. There are few cases where I truly prefer dynamic types to static ones.

pacala 7y ago

'you can write purely functionally in Python'. I wish https://github.com/tobgu/pyrsistent https://github.com/tobgu/pyrsistent were more mainstream in the Python community and get some syntax love.