4 ms·

That's a good use of Python, and if that's all it's useful for for you, that's fine. I'm not sure whether or not you're trying to argue that that is the only re

That's a good use of Python, and if that's all it's useful for for you, that's fine. I'm not sure whether or not you're trying to argue that that is the only reaosnable use of Python? To me, it sound like you are. If so, that is contradicted by the many people who have successfully used Python for many other purposes. That includes run-once scripts (where you might have used Perl in the past) where run time speed is not as important as speed of writing the code, but also certain types of code running in production. Like any other tool, you have to be aware of its strengths and weaknesses: maybe it's not the best choice for a code base running into 10s of KLOC or more, or for doing CPU-intensive work that can't be vectorised (e.g. multiplying a few large matrices in numpy is fine, whereas multiplying an extremely large number of very small matrices is maybe not fine). The fact it has weaknesses doesn't mean it should be written off for all tasks, even those where the weaknesses aren't so important, especially when it has strengths too (e.g. if Python would do for a particular task then using C++ blindly because it's "better" would be wasting developer time for no reason). It's often used for glue code where all the work is actually done in C libraries like deep learning, and it works very well for that: if 0.1% of your runtime is spent in the top-level glue instead of 0.01%, that's probably not a problem. Also, this discussion is fairly off topic to begin with. The article really isn't about the strengths and weaknesses of the language. It's about what consitutes the language versus an implementation of it (CPython).

tannhaeuser 6y ago
I guess what I'm trying to say is that Python is fine as it is; I believe (relatively) recent additions such type annotations and chasing trends like async only serve to question Python's core strength. I know full well that Python is used a lot for "scripting" tasks (such as in yum/dnf and countless others), and has apparently a good standing in ML; in fact I'm using it daily (for example, I'm using BackInTime for backup). But whenever I come across eg. Python bindings in a package I want to compile, or Python used as part of a build step, I know I'm in for extra work since rarely does it work out of the box (relying on fragile "/usr/bin/env python" hashbangs, or having me to manoever around missing Python packages or versions, etc.). Saying this from the perspective of someone who has seen shell alternatives come and go, even Perl has, in practice, better backward-compat and has generally aged better. But yeah, it's offtopic I guess.
- greenshackle2 6y ago
  > chasing trends like async Python is fairly popular for web backends, given the ecosystem built around WSGI, I would say that's one of its core strength, so async makes obvious sense.
- VectorLock 6y ago
  Python does have some warts with like you said hashbangs but its still eons ahead of other similar languages in this regard (like Ruby) and that is a small thing to relegate it in your mind to a 'beginner only' language, since tons of other languages do things much worse than Python does. Python's simplicity - which makes it appealing for beginners - is its core strength that had made it so widely adopted for so many different things.
6gvONxR4sf7o 6y ago
> That includes run-once scripts (where you might have used Perl in the past) I never learned perl, but nearly every time I try to do something complex in bash (more than a dozen lines or so containing control flow) I regret it and end up rewriting it in python. Then the next time comes around and I go "I really should get better at shell scripting, I'll do that," and bash my head against the wall for a while then end up going back to python again.
- lioeters 6y ago
  > bash my head against the wall for a while I'm similar with shell scripts - awkward at best. The longest one I've written is only a few hundred lines, but it was tough to write and test. It sits in the middle of a busy build pipeline, and while it does the job, I'm wary of making any changes. For long-term maintenance, especially for other people that may need to keep it runnning, I'd trade some performance for a higher-level language like Python or JavaScript - the code and logic would be so much simpler.

tannhaeuser 6y ago

I guess what I'm trying to say is that Python is fine as it is; I believe (relatively) recent additions such type annotations and chasing trends like async only serve to question Python's core strength. I know full well that Python is used a lot for "scripting" tasks (such as in yum/dnf and countless others), and has apparently a good standing in ML; in fact I'm using it daily (for example, I'm using BackInTime for backup). But whenever I come across eg. Python bindings in a package I want to compile, or Python used as part of a build step, I know I'm in for extra work since rarely does it work out of the box (relying on fragile "/usr/bin/env python" hashbangs, or having me to manoever around missing Python packages or versions, etc.). Saying this from the perspective of someone who has seen shell alternatives come and go, even Perl has, in practice, better backward-compat and has generally aged better. But yeah, it's offtopic I guess.

greenshackle2 6y ago
> chasing trends like async Python is fairly popular for web backends, given the ecosystem built around WSGI, I would say that's one of its core strength, so async makes obvious sense.
VectorLock 6y ago
Python does have some warts with like you said hashbangs but its still eons ahead of other similar languages in this regard (like Ruby) and that is a small thing to relegate it in your mind to a 'beginner only' language, since tons of other languages do things much worse than Python does. Python's simplicity - which makes it appealing for beginners - is its core strength that had made it so widely adopted for so many different things.

6gvONxR4sf7o 6y ago

> That includes run-once scripts (where you might have used Perl in the past) I never learned perl, but nearly every time I try to do something complex in bash (more than a dozen lines or so containing control flow) I regret it and end up rewriting it in python. Then the next time comes around and I go "I really should get better at shell scripting, I'll do that," and bash my head against the wall for a while then end up going back to python again.

lioeters 6y ago
> bash my head against the wall for a while I'm similar with shell scripts - awkward at best. The longest one I've written is only a few hundred lines, but it was tough to write and test. It sits in the middle of a busy build pipeline, and while it does the job, I'm wary of making any changes. For long-term maintenance, especially for other people that may need to keep it runnning, I'd trade some performance for a higher-level language like Python or JavaScript - the code and logic would be so much simpler.