8 ms·

Because you can do a lot with little typing and there are lots of great libraries. Python is probably the best choice when you need to get something done quick

Because you can do a lot with little typing and there are lots of great libraries. Python is probably the best choice when you need to get something done quick or calculate something when performance is not important. It is also not an exotic functional language without loops and filled with linked lists. Also, in Python integers do not overflow, unlike in Rust, C and other buggy languages. If you name a language, with high probability Python will be better in something unless it is about performance. What I don't like: no type hints in many libraries, some libraries are not type-hint friendly, lot of unnecessary dynmamic features (like being able to patch modules in runtime) and absolutely no caring about performance and being able to compile into machine code. > trying to figure out what some dynamically typed code is doing There should be type hints.

toomanydoubts 4y ago
>There should be type hints. "Hey, this variable is probably of this type. Now go on, run the code and launch a debugger the same way you would if there was no hint just to make sure it's correct. Oh, and don't forget to check all the possible code paths that lead to this to make sure you've exhausted all possibilities." Don't get me wrong, type hints are cool but they're just a toy compared to proper static typing.
- joshuamorton 4y ago
  > Oh, and don't forget to check all the possible code paths that lead to this to make sure you've exhausted all possibilities." This is literally what mypy does. There's no difference between a mypy-enabled codebase and a java codebase in terms of static typing (other than that mypy actually supports a generally richer type system). Like yes if you aren't validating the type hints you aren't getting the value, but if you are, you don't need to run the code! I get most of my python errors at compile time, and you can too. I promise.
  - FridgeSeal 4y ago
    Sorry, but MyPy and friends can barely hold a candle to what actual static-typing systems do - Rust, Haskell, OCaml, Typescript, even .Net (C#/F#) offer more safety and guarantees. Type hints in python are _just that_, they're hints. The whole "typed" python ecosystem relies on packages and the language using them, using them correctly, and using them consistently. In my experience so far, I've seen little widespread use, and nothing from core python, which is a huge hole IMO.
    - joshuamorton 4y ago
      > Sorry, but MyPy and friends can barely hold a candle to what actual static-typing systems do - Rust, Haskell, OCaml, Typescript, even .Net (C#/F#) offer more safety and guarantees. Note that you don't include the most common static languages there (cpp, java, golang), you include languages known *specifically " for their extremely powerful type systems, one of which , just like mypy, uses gradual typing! This supports my argument!
      - FridgeSeal 4y ago
        I mean sure, we can include C++, go and java in there if you want? I don’t really know what the point you’re making here is? > one of which , just like mypy, uses gradual typing! This is like arguing that because your scooter also has a petrol engine, it’s as fast and efficient as an F1 car. My argument was that MyPy doesn’t compete with the capabilities of modern statically typed languages. TS might also technically be gradually typed, but most devs I know just go straight to fully typed TS, because working in a mix/gradual environment is painful and the community uptake of strict types is far higher.
        joshuamorton 4y ago
        What features that Javas type system provides does pythons lack? I can name dozens that python has that Java doesn't. My point is that if you include cpp or java or golang the statement becomes false. Python's type system is actually generally speaking more robust than those (cpp is comparable, but I don't think python's is worse). So I'm asking, be specific what capabilities does mypy lack that cpp or java or golang provide? Keep in mind, mypy supports literal types, limited dependent types, dynamic-duck typing (protocols), limited contract types, and more. Java doesn't, go doesn't. Cpp supports some of those but it requires arcane incantations.
  - mdaniel 4y ago
    > There's no difference between a mypy-enabled codebase and a java codebase in terms of static typing (other than that mypy actually supports a generally richer type system). that must require some advanced usage of mypy then, because my experience was that even the most simple example got the finger from mypy that would have very obviously worked in Java mkdir alpha echo 'beta = True' > alpha/models.py echo 'from .models import beta' > alpha/__init__.py echo 'import alpha; print(alpha.beta)' > doit.py mypy --strict doit.py # doit.py:1: error: Module has no attribute "beta" And look, I'm with you that I wish any codebase with an `__init__.py` anywhere in it (thus, what I think of as a project versus some ad-hoc python scripting whatever) would type-hint the absolute hell out of things, but claiming mypy or any such linting system is as strict as a strongly typed language always boils my blood
    - still_grokking 4y ago
      It's imho especially ridiculous to say some linter, that needs "hints" and annotations everywhere, is comparable to a static type system when looking at modern static languages, which have usually very strong type inference. The point of a sound static type system is that you get a guaranty that your program is type-safe even in case not everything is "hinted properly". With the linter approach on the other hands side it won't get better than what a dynamic language offers anyway: To be (more or less) sure everything is like intended all you can do is to run your program and pray… You can't upfront rule out for sure all kinds of errors like when using a proper static language.
      - mdaniel 4y ago
        Did you reply to the right person? I'm with you, friend :-)
        still_grokking 4y ago
        I think I did not object anything you've said. :-) I only wanted to point out once more that a proper static type system is of more use than some bolted on linter. (And add the point about type inference).
  - raydev 4y ago
    > This is literally what mypy does. Kinda silly that this is optional tooling that came from the community to solve a problem in the original implementation. Sure, having a community and general inertia, because Python is simply good enough and no alternative has a killer feature, is certainly something you can rely on. It's okay to ask for more, though.
  - smabie 4y ago
    The number of "# type: ignore" comments I've seen in all python codebases that use mypy seems to disagree. mypy is laughably primitive compared to advanced static typing systems: Rust, Haskell, OCaml, etc
    - joshuamorton 4y ago
      > mypy is laughably primitive compared to advanced static typing systems I don't disagree, but that's not an argument I ever put forth! (and I actually sort of disagree a little bit, mypy has/is getting a bunch of really cool powerful features that put it in the realm of "as cool as" those languages: PEPs 544, 586, 591, 647 (this is a weak form of contract types!), 675 (~constexpr string type), 646 (variadic generic/numeric dependent types!))
toomanydoubts 4y ago
>no type hints in many libraries, some libraries are not type-hint friendly. >There should be type hints. So, is it one or the other?
peaky_blinder 4y ago
> Also, in Python integers do not overflow, unlike in Rust, C and other buggy languages. There is no such thing as a buggy language. Software can be buggy (or language implementation), but not the language. And the reason you do not have integer overflow is because integers are implemented as integer objects of arbitrary size, which is great if you're doing something quick and dirty, but could be disastrous for a serious work.
- still_grokking 4y ago
  > There is no such thing as a buggy language. How can you know if you don't have a verified formal description of your language's semantics? It's very much possible (and imho even quite likely) that a lot of language definitions are self contradicting. Of course one could argue that such self contradictions aren't "bugs" at all. But such an argumentation would seem very odd, imho, no matter one can actually "define" whatever one likes.
  - hnfong 4y ago
    http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-... > Signed integer overflow: If arithmetic on an 'int' type (for example) overflows, the result is undefined. One example is that "INT_MAX+1" is not guaranteed to be INT_MIN. Probably not what the GP meant, but I think this qualifies as a "buggy language (spec)"
    - still_grokking 4y ago
      I don't think defining something as undefined is buggy per se. That's not what I've meant. But defining some things in a contradicting manner would make up a buggy spec, I guess. Regarding the int example, funny enough I made a comment about that just before here: https://news.ycombinator.com/item?id=32457056 https://news.ycombinator.com/item?id=32457056
- dannymi 4y ago
  >could be disastrous for a serious work. How so?
elcritch 4y ago
Wow, I thought Rust's integers would let you handle integer overflows.. Apparently thats not the case and overflows are only checked in debug builds and then they just panic. Huh. After programming in Nim (and Python back in the day), I've become used to being able to detect integer overflows as a normal exception. At least for signed ints, since not all CPU support efficient overflow detection on unsigned ints. Its handy to to let uints wrap as sometimes thats what you want. I figured all new languages would do similar things.
- bobbylarrybobby 4y ago
  Rust has a variety of checked methods -- `checked_add` etc -- that allow for fallible int operations. And there are corresponding `wrapping_` versions that indicate wrapping is the correct behavior (and shouldn't panic in debug builds).
chaxor 4y ago
What i don't like about python: The goddamn versioning and packaging problems. About 5 years ago python was incredible. You could pop out a project quickly because there were very few packages that made breaking changes over their development, so you could often use your standard workflow with the set of packages you we're comfortable with, even if there were new versions available that day. Now, Nvidia and Google ruined everything. Python is the ML language, so every package likely depends somehow on tensorflow or some GPU acceleration. This is a problem because every damn version of ' insert tf/pytorch/Jax/cuda/etc ml package here' only works with that exact version configuration ONLY ( and honestly, it probably doesn't actually work anyway). So, if you have an idea of using two packages together that aren't already in a package - be prepared to spend the next month trying in despair to get that to work (and probably ultimately give up). It's insane to me that the workflow of today necessitates (in python anyway) setting up multiple docker containers to talk to each other, simply because python packages seem to have no problem making breaking changes every freaking week.
- echelon 4y ago
  I feel this comment in my bones. I went from loving Python to hating it with a seething rage. Python package managers are all so bad that the only reasonable solution is Docker containers or vendoring everything (not easy). And even so, I've had untouched Docker builds still die because dependencies mysteriously get yanked or changed. God, I hate Python so much now.
  - still_grokking 4y ago
    If you like the look & feel of Python, but not the ecosystem: https://docs.scala-lang.org/scala3/book/scala-for-python-devs.html https://docs.scala-lang.org/scala3/book/scala-for-python-dev... Sorry for that quite random comment, but SCNR.
    - theblazehen 4y ago
      Thanks for that! I've heard about scala before, never investigated it. I'm really looking the like of it now
kevin_thibedeau 4y ago
Overflowing integers is not a bug. It's literally how an adder circuit operates on fixed precision. Ignoring them by default is worth criticizing but there are plenty of times where silent overflow is correct and desirable behavior.
- tomp 4y ago
  It's technically not a "bug" in Rust or C++, it's undefined behaviour, which is much worse than a bug! (and it's never correct behaviour)
  - still_grokking 4y ago
    Little nitpick: In C/C++ it's "only" UB for signed ints. For unsigned ints it's arithmetic modulo 2^n (where n is the number of bits in the value representation of that particular size of integer). Such divergent definitions make the whole mess of course even bigger, that's not the point.
    - pratk 4y ago
      Also, the UB can be mitigated with -fwrapv (if desired) to handle overflowing integers with 2's complement
      - still_grokking 4y ago
        Stupid question, but how can a compiler flag "mitigate" some UB that is (to my knowledge) defined by the standard as UB? This would be possible only if the standard would define the behavior in question as implementation defined. But that's not the case afaik. Signed overflow is undefined behavior as it's afaik defined to be that. But maybe I'm just wrong here? But at least SO is confining my knowledge: https://stackoverflow.com/questions/16188263/is-signed-integer-overflow-still-undefined-behavior-in-c https://stackoverflow.com/questions/16188263/is-signed-integ...
        4y ago
HdS84 4y ago
For runtime patching: I needed that twice: First there was a bug in the stdlib event log logging for windows which crashed when the user was not an admin (2.7 days). We could monkey patch that problem on the fly which was much better than any alternative. Second I needed to redirect scikitlearn logging to a file. Which did not work because scikit does not use logging but something homegrown. We just overwrite the internal log function and all was good. Yes it's seldom needed and it's a very sharp sword but it's much better that it's there when you need it. I encountered bugs in .net stdlib which where there was no alternative than to wait for the next release. Very ugly when you need to ship.
dexterlemmer 4y ago
Type hints and static typing are completely orthogonal. It is merely more common for the designers of dynamically typed languages to make the mistake of not allowing type hints pretty much every where and requiring them in a library's API (or at least linting for them being missing in the API) than making the same mistake is for the designers of staically typed languages.

toomanydoubts 4y ago

>There should be type hints. "Hey, this variable is probably of this type. Now go on, run the code and launch a debugger the same way you would if there was no hint just to make sure it's correct. Oh, and don't forget to check all the possible code paths that lead to this to make sure you've exhausted all possibilities." Don't get me wrong, type hints are cool but they're just a toy compared to proper static typing.

joshuamorton 4y ago
> Oh, and don't forget to check all the possible code paths that lead to this to make sure you've exhausted all possibilities." This is literally what mypy does. There's no difference between a mypy-enabled codebase and a java codebase in terms of static typing (other than that mypy actually supports a generally richer type system). Like yes if you aren't validating the type hints you aren't getting the value, but if you are, you don't need to run the code! I get most of my python errors at compile time, and you can too. I promise.
- FridgeSeal 4y ago
  Sorry, but MyPy and friends can barely hold a candle to what actual static-typing systems do - Rust, Haskell, OCaml, Typescript, even .Net (C#/F#) offer more safety and guarantees. Type hints in python are _just that_, they're hints. The whole "typed" python ecosystem relies on packages and the language using them, using them correctly, and using them consistently. In my experience so far, I've seen little widespread use, and nothing from core python, which is a huge hole IMO.
  - joshuamorton 4y ago
    > Sorry, but MyPy and friends can barely hold a candle to what actual static-typing systems do - Rust, Haskell, OCaml, Typescript, even .Net (C#/F#) offer more safety and guarantees. Note that you don't include the most common static languages there (cpp, java, golang), you include languages known *specifically " for their extremely powerful type systems, one of which , just like mypy, uses gradual typing! This supports my argument!
    - FridgeSeal 4y ago
      I mean sure, we can include C++, go and java in there if you want? I don’t really know what the point you’re making here is? > one of which , just like mypy, uses gradual typing! This is like arguing that because your scooter also has a petrol engine, it’s as fast and efficient as an F1 car. My argument was that MyPy doesn’t compete with the capabilities of modern statically typed languages. TS might also technically be gradually typed, but most devs I know just go straight to fully typed TS, because working in a mix/gradual environment is painful and the community uptake of strict types is far higher.
      - joshuamorton 4y ago
        What features that Javas type system provides does pythons lack? I can name dozens that python has that Java doesn't. My point is that if you include cpp or java or golang the statement becomes false. Python's type system is actually generally speaking more robust than those (cpp is comparable, but I don't think python's is worse). So I'm asking, be specific what capabilities does mypy lack that cpp or java or golang provide? Keep in mind, mypy supports literal types, limited dependent types, dynamic-duck typing (protocols), limited contract types, and more. Java doesn't, go doesn't. Cpp supports some of those but it requires arcane incantations.
- mdaniel 4y ago
  > There's no difference between a mypy-enabled codebase and a java codebase in terms of static typing (other than that mypy actually supports a generally richer type system). that must require some advanced usage of mypy then, because my experience was that even the most simple example got the finger from mypy that would have very obviously worked in Java mkdir alpha echo 'beta = True' > alpha/models.py echo 'from .models import beta' > alpha/__init__.py echo 'import alpha; print(alpha.beta)' > doit.py mypy --strict doit.py # doit.py:1: error: Module has no attribute "beta" And look, I'm with you that I wish any codebase with an `__init__.py` anywhere in it (thus, what I think of as a project versus some ad-hoc python scripting whatever) would type-hint the absolute hell out of things, but claiming mypy or any such linting system is as strict as a strongly typed language always boils my blood
  - still_grokking 4y ago
    It's imho especially ridiculous to say some linter, that needs "hints" and annotations everywhere, is comparable to a static type system when looking at modern static languages, which have usually very strong type inference. The point of a sound static type system is that you get a guaranty that your program is type-safe even in case not everything is "hinted properly". With the linter approach on the other hands side it won't get better than what a dynamic language offers anyway: To be (more or less) sure everything is like intended all you can do is to run your program and pray… You can't upfront rule out for sure all kinds of errors like when using a proper static language.
    - mdaniel 4y ago
      Did you reply to the right person? I'm with you, friend :-)
      - still_grokking 4y ago
        I think I did not object anything you've said. :-) I only wanted to point out once more that a proper static type system is of more use than some bolted on linter. (And add the point about type inference).
- raydev 4y ago
  > This is literally what mypy does. Kinda silly that this is optional tooling that came from the community to solve a problem in the original implementation. Sure, having a community and general inertia, because Python is simply good enough and no alternative has a killer feature, is certainly something you can rely on. It's okay to ask for more, though.
- smabie 4y ago
  The number of "# type: ignore" comments I've seen in all python codebases that use mypy seems to disagree. mypy is laughably primitive compared to advanced static typing systems: Rust, Haskell, OCaml, etc
  - joshuamorton 4y ago
    > mypy is laughably primitive compared to advanced static typing systems I don't disagree, but that's not an argument I ever put forth! (and I actually sort of disagree a little bit, mypy has/is getting a bunch of really cool powerful features that put it in the realm of "as cool as" those languages: PEPs 544, 586, 591, 647 (this is a weak form of contract types!), 675 (~constexpr string type), 646 (variadic generic/numeric dependent types!))

toomanydoubts 4y ago

>no type hints in many libraries, some libraries are not type-hint friendly. >There should be type hints. So, is it one or the other?

peaky_blinder 4y ago

> Also, in Python integers do not overflow, unlike in Rust, C and other buggy languages. There is no such thing as a buggy language. Software can be buggy (or language implementation), but not the language. And the reason you do not have integer overflow is because integers are implemented as integer objects of arbitrary size, which is great if you're doing something quick and dirty, but could be disastrous for a serious work.

still_grokking 4y ago
> There is no such thing as a buggy language. How can you know if you don't have a verified formal description of your language's semantics? It's very much possible (and imho even quite likely) that a lot of language definitions are self contradicting. Of course one could argue that such self contradictions aren't "bugs" at all. But such an argumentation would seem very odd, imho, no matter one can actually "define" whatever one likes.
- hnfong 4y ago
  http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-... > Signed integer overflow: If arithmetic on an 'int' type (for example) overflows, the result is undefined. One example is that "INT_MAX+1" is not guaranteed to be INT_MIN. Probably not what the GP meant, but I think this qualifies as a "buggy language (spec)"
  - still_grokking 4y ago
    I don't think defining something as undefined is buggy per se. That's not what I've meant. But defining some things in a contradicting manner would make up a buggy spec, I guess. Regarding the int example, funny enough I made a comment about that just before here: https://news.ycombinator.com/item?id=32457056 https://news.ycombinator.com/item?id=32457056
dannymi 4y ago
>could be disastrous for a serious work. How so?

elcritch 4y ago

Wow, I thought Rust's integers would let you handle integer overflows.. Apparently thats not the case and overflows are only checked in debug builds and then they just panic. Huh. After programming in Nim (and Python back in the day), I've become used to being able to detect integer overflows as a normal exception. At least for signed ints, since not all CPU support efficient overflow detection on unsigned ints. Its handy to to let uints wrap as sometimes thats what you want. I figured all new languages would do similar things.

bobbylarrybobby 4y ago
Rust has a variety of checked methods -- `checked_add` etc -- that allow for fallible int operations. And there are corresponding `wrapping_` versions that indicate wrapping is the correct behavior (and shouldn't panic in debug builds).

chaxor 4y ago

What i don't like about python: The goddamn versioning and packaging problems. About 5 years ago python was incredible. You could pop out a project quickly because there were very few packages that made breaking changes over their development, so you could often use your standard workflow with the set of packages you we're comfortable with, even if there were new versions available that day. Now, Nvidia and Google ruined everything. Python is the ML language, so every package likely depends somehow on tensorflow or some GPU acceleration. This is a problem because every damn version of ' insert tf/pytorch/Jax/cuda/etc ml package here' only works with that exact version configuration ONLY ( and honestly, it probably doesn't actually work anyway). So, if you have an idea of using two packages together that aren't already in a package - be prepared to spend the next month trying in despair to get that to work (and probably ultimately give up). It's insane to me that the workflow of today necessitates (in python anyway) setting up multiple docker containers to talk to each other, simply because python packages seem to have no problem making breaking changes every freaking week.

echelon 4y ago
I feel this comment in my bones. I went from loving Python to hating it with a seething rage. Python package managers are all so bad that the only reasonable solution is Docker containers or vendoring everything (not easy). And even so, I've had untouched Docker builds still die because dependencies mysteriously get yanked or changed. God, I hate Python so much now.
- still_grokking 4y ago
  If you like the look & feel of Python, but not the ecosystem: https://docs.scala-lang.org/scala3/book/scala-for-python-devs.html https://docs.scala-lang.org/scala3/book/scala-for-python-dev... Sorry for that quite random comment, but SCNR.
  - theblazehen 4y ago
    Thanks for that! I've heard about scala before, never investigated it. I'm really looking the like of it now

kevin_thibedeau 4y ago

Overflowing integers is not a bug. It's literally how an adder circuit operates on fixed precision. Ignoring them by default is worth criticizing but there are plenty of times where silent overflow is correct and desirable behavior.

tomp 4y ago
It's technically not a "bug" in Rust or C++, it's undefined behaviour, which is much worse than a bug! (and it's never correct behaviour)
- still_grokking 4y ago
  Little nitpick: In C/C++ it's "only" UB for signed ints. For unsigned ints it's arithmetic modulo 2^n (where n is the number of bits in the value representation of that particular size of integer). Such divergent definitions make the whole mess of course even bigger, that's not the point.
  - pratk 4y ago
    Also, the UB can be mitigated with -fwrapv (if desired) to handle overflowing integers with 2's complement
    - still_grokking 4y ago
      Stupid question, but how can a compiler flag "mitigate" some UB that is (to my knowledge) defined by the standard as UB? This would be possible only if the standard would define the behavior in question as implementation defined. But that's not the case afaik. Signed overflow is undefined behavior as it's afaik defined to be that. But maybe I'm just wrong here? But at least SO is confining my knowledge: https://stackoverflow.com/questions/16188263/is-signed-integer-overflow-still-undefined-behavior-in-c https://stackoverflow.com/questions/16188263/is-signed-integ...
      - 4y ago

HdS84 4y ago

For runtime patching: I needed that twice: First there was a bug in the stdlib event log logging for windows which crashed when the user was not an admin (2.7 days). We could monkey patch that problem on the fly which was much better than any alternative. Second I needed to redirect scikitlearn logging to a file. Which did not work because scikit does not use logging but something homegrown. We just overwrite the internal log function and all was good. Yes it's seldom needed and it's a very sharp sword but it's much better that it's there when you need it. I encountered bugs in .net stdlib which where there was no alternative than to wait for the next release. Very ugly when you need to ship.

dexterlemmer 4y ago

Type hints and static typing are completely orthogonal. It is merely more common for the designers of dynamically typed languages to make the mistake of not allowing type hints pretty much every where and requiring them in a library's API (or at least linting for them being missing in the API) than making the same mistake is for the designers of staically typed languages.