4 ms·

I'd like to hear why you think Python is as bad

by asdsa5325 8y ago

spraak 8y ago
Horrible package management story. Cross platform is a headache. Slow.
- asdsa5325 8y ago
  Cross-platform in Python is not a headache? Yeah, it's a bit slow. It's faster than Javascript, though. The best benefit is flexible number size, so it's good for some types of computation. What improvements in package management would you want? At least it has some form of management, unlike C/C++...
staticassertion 8y ago
2 or 3? Or all of the problems that come with choosing between the two (no, it is still not an easy choice). Mypy coverage, even in the stdlib, is awful. When it comes to thirdparty, mostly nonexistent. Mypy feels so young - I love the team, love their work, but I still run into cases where inference fails when it shouldn't, where error messages are extremely unhelpful, etc. Slow. Plenty of 'wat' like mistakes: https://stackoverflow.com/questions/3270680/how-does-python-compare-string-and-int https://stackoverflow.com/questions/3270680/how-does-python-... Exceptions everywhere, for control flow even - iterators are implemented with exceptions. Absolutely AOT unoptimizable. Pypy's cool, never got it working for my use case. In theory a JIT could help. Speaking of calling out to C... you think you're writing in a memory safe language, but actually, you're writing in a memory safe language that's probably been hollowed out and replaced with a fast C implementation. But it's actually worse https://hackernoon.com/python-sandbox-escape-via-a-memory-corruption-bug-19dde4d5fea5 https://hackernoon.com/python-sandbox-escape-via-a-memory-co... Exploiting C code loaded by Python is like exploiting C code from the 1990s. No parallelism. Multiprocessing? Good luck with that - pay the cost of pickling, pay the cost of an additional interpreter, pay the cost of debugging hell. An ecosystem split in two, and don't let anyone tell you otherwise - a few hundred top packages moving over after many, many years, is a sad state for a language that was known for having an absurdly large ecosystem. I could really just go on and on and on, but at some point it just feels mean. Huge respect for the project and the team but Python has made mistakes (as all languages do). They were understandable mistakes, but they were mistakes. It's fine for some things, but there's plenty wrong with it, just like there's a ton wrong with javascript. But javascript gets probably 1000x the flack.
- weberc2 8y ago
  > no, it is still not an easy choice Yeah it is, choose 3. Python 2 is reaching EOL. > Mypy coverage, even in the stdlib, is awful. When it comes to thirdparty, mostly nonexistent. Mypy feels so young - I love the team, love their work, but I still run into cases where inference fails when it shouldn't, where error messages are extremely helpful, etc. Yeah, the typing stuff is a pretty big disappointment. The ergonomics are pretty terrible (probably because they wanted to push as far as they could without introducing more syntax support for typing). Mypy isn't just young, but it's buggy and its codebase was a sloppy mess last I checked. There's no support for recursive types (you can't define a JSON type, for example). And it absolutely falls over in the face of common libraries, like SQLAlchemy, which are too dynamic for it. > Absolutely AOT unoptimizable. Pypy's cool, never got it working for my use case. In theory a JIT could help. Yeah, Pypy is the best hope for Python's performance. They're making great progress, but I also couldn't get it working in our Python 3 codebase (Numpy and Pandas installation issues). > No parallelism. Multiprocessing? Good luck with that - pay the cost of pickling, pay the cost of an additional interpreter, pay the cost of debugging hell. Yeah, this is a real pain point. Some die-hard Python folks say otherwise, but there's really no good parallelism option for lots of workloads. Pickling is just too expensive. > An ecosystem split in two, and don't let anyone tell you otherwise - a few hundred top packages moving over after many, many years, is a sad state for a language that was known for having an absurdly large ecosystem. This hasn't been a problem for me for years. Most things that have seen active development in the last 5 years have good Python 3 support. The only time I've run into a Python-2 only utility, it was 7 years stale. Well, except for Centos's `yum`. These are all reasons I like Go, by the way. Super fast, great tooling, and fairly stable (except for the package management story). I do wish there was a lightweight scripting language with a great VM and real parallelism--something like JS without the inheritance, OO baggage, etc; just objects and arrays and functions running on a JIT VM like V8 but with parallelism as a first-class citizen a la BEAM. And preferably optionally typed from the start, in a way that the runtime could leverage for optimization purposes.
  - staticassertion 8y ago
    > Yeah it is, choose 3. Python 2 is reaching EOL. Easy to say. Tell that to Google and Dropbox - Guido has worked for both and they're on 2. Tell that to the companies that can't afford the creator of the language. 3 is not the easy choice. Anyways, maybe try nim? I've heard good things.

I'd like to hear why you think Python is as bad

spraak 8y ago

Horrible package management story. Cross platform is a headache. Slow.

asdsa5325 8y ago
Cross-platform in Python is not a headache? Yeah, it's a bit slow. It's faster than Javascript, though. The best benefit is flexible number size, so it's good for some types of computation. What improvements in package management would you want? At least it has some form of management, unlike C/C++...

staticassertion 8y ago

2 or 3? Or all of the problems that come with choosing between the two (no, it is still not an easy choice). Mypy coverage, even in the stdlib, is awful. When it comes to thirdparty, mostly nonexistent. Mypy feels so young - I love the team, love their work, but I still run into cases where inference fails when it shouldn't, where error messages are extremely unhelpful, etc. Slow. Plenty of 'wat' like mistakes: https://stackoverflow.com/questions/3270680/how-does-python-compare-string-and-int https://stackoverflow.com/questions/3270680/how-does-python-... Exceptions everywhere, for control flow even - iterators are implemented with exceptions. Absolutely AOT unoptimizable. Pypy's cool, never got it working for my use case. In theory a JIT could help. Speaking of calling out to C... you think you're writing in a memory safe language, but actually, you're writing in a memory safe language that's probably been hollowed out and replaced with a fast C implementation. But it's actually worse https://hackernoon.com/python-sandbox-escape-via-a-memory-corruption-bug-19dde4d5fea5 https://hackernoon.com/python-sandbox-escape-via-a-memory-co... Exploiting C code loaded by Python is like exploiting C code from the 1990s. No parallelism. Multiprocessing? Good luck with that - pay the cost of pickling, pay the cost of an additional interpreter, pay the cost of debugging hell. An ecosystem split in two, and don't let anyone tell you otherwise - a few hundred top packages moving over after many, many years, is a sad state for a language that was known for having an absurdly large ecosystem. I could really just go on and on and on, but at some point it just feels mean. Huge respect for the project and the team but Python has made mistakes (as all languages do). They were understandable mistakes, but they were mistakes. It's fine for some things, but there's plenty wrong with it, just like there's a ton wrong with javascript. But javascript gets probably 1000x the flack.

weberc2 8y ago
> no, it is still not an easy choice Yeah it is, choose 3. Python 2 is reaching EOL. > Mypy coverage, even in the stdlib, is awful. When it comes to thirdparty, mostly nonexistent. Mypy feels so young - I love the team, love their work, but I still run into cases where inference fails when it shouldn't, where error messages are extremely helpful, etc. Yeah, the typing stuff is a pretty big disappointment. The ergonomics are pretty terrible (probably because they wanted to push as far as they could without introducing more syntax support for typing). Mypy isn't just young, but it's buggy and its codebase was a sloppy mess last I checked. There's no support for recursive types (you can't define a JSON type, for example). And it absolutely falls over in the face of common libraries, like SQLAlchemy, which are too dynamic for it. > Absolutely AOT unoptimizable. Pypy's cool, never got it working for my use case. In theory a JIT could help. Yeah, Pypy is the best hope for Python's performance. They're making great progress, but I also couldn't get it working in our Python 3 codebase (Numpy and Pandas installation issues). > No parallelism. Multiprocessing? Good luck with that - pay the cost of pickling, pay the cost of an additional interpreter, pay the cost of debugging hell. Yeah, this is a real pain point. Some die-hard Python folks say otherwise, but there's really no good parallelism option for lots of workloads. Pickling is just too expensive. > An ecosystem split in two, and don't let anyone tell you otherwise - a few hundred top packages moving over after many, many years, is a sad state for a language that was known for having an absurdly large ecosystem. This hasn't been a problem for me for years. Most things that have seen active development in the last 5 years have good Python 3 support. The only time I've run into a Python-2 only utility, it was 7 years stale. Well, except for Centos's `yum`. These are all reasons I like Go, by the way. Super fast, great tooling, and fairly stable (except for the package management story). I do wish there was a lightweight scripting language with a great VM and real parallelism--something like JS without the inheritance, OO baggage, etc; just objects and arrays and functions running on a JIT VM like V8 but with parallelism as a first-class citizen a la BEAM. And preferably optionally typed from the start, in a way that the runtime could leverage for optimization purposes.
- staticassertion 8y ago
  > Yeah it is, choose 3. Python 2 is reaching EOL. Easy to say. Tell that to Google and Dropbox - Guido has worked for both and they're on 2. Tell that to the companies that can't afford the creator of the language. 3 is not the easy choice. Anyways, maybe try nim? I've heard good things.