I mean, it’s still a very nice language. I can see someone, marveled by that, would endeavor to make bigger things with it. I just don’t feel it scales that well.
My own hot take is that I hear this criticism of Python a lot, but have never had anyone actually back it up when I ask for more details. And I will be very surprised to hear that it’s a worse situation than Java/TypeScript’s.
We used to have a Python guy at my work. For a lot of LITTLE ETL stuff he created Python projects. In two projects I’ve had to fix up now, he used different tooling. Both those toolings have failed me (Poetry, Conda). I ended up using our CI/CD pipeline code to run my local stuff, because I could not get those things to work.
For comparison, it took me roughly zero seconds to start working on an old Go project.
Python was built in an era where space was expensive and it was only used for small, universal scripts. In that context, having all packages be “system-wide” made sense. All the virtual env shenanigans won’t ever fix that.
In that context, having all packages be “system-wide” made sense. All the virtual env shenanigans won’t ever fix that.
Sorry, but you’ll need to explain this a little bit more to me. That’s precisely what virtual env shenanigans do - make it so that your environment isn’t referencing the system-wide packages. I can totally see that it’s a problem if your virtual env tooling fails to work as expected and you can’t activate your environment (FWIW, simply old python -m venv venv; source venv/bin/activate has never let me down in ~10 years of professional programming, but I do believe you when you say that Poetry and Conda have broken on you); but assuming that the tools work, the problem you’ve described completely goes away.
The endless packaging solutions for python is exactly the flaw that they’re talking about.
Packaging a python application to work over an air-gap is extremely painful. Half the time its easier to make a docker container or VM just to avoid the endless version mismatch pain.
I don’t think the length of program matters so much, especially with type hints making it easier to maintain larger projects.
That being said, it’s pretty well known in the community that distributing any kind of end user software is a nightmare with python (though there’s a small group of people who insist that it’s not that hard to get people to install python to run their program. Those people are nuts).
The biggest reason I use python for as many projects as is practical, though, is because it has an incredible community that I love to interact with. Unless I truly need something to be scalable, python is always going to be my hammer of choice.
I don’t mean it doesn’t work for larger projects. Just that it’s a pain to understand other’s code when you have almost no type information, making it, to me, a no go for that
Larger projects in Python (like homeassistant) tend to use type-hints and enforce them through linters. Essentially, these linters (with a well-setup IDE) turn programming in large Python projects into a very similar experience to programming a statically typed language, except that Python does not need to be compiled (and type-checked) to run it. So you can still run it before you have satisfied the linters, you just can’t commit or push or whatever (depending on project setup).
And yes, these linters and the Python type system are obviously not as good as something like a Go or Rust compiler. But then again, Python is a generalist language: it can do everything, but excels at nothing.
Go and rust are also generalist languages. Basically all main stream programming languages are and are equally as powerful (in terms of what they can do, rather than performance) as each other as they are all Turing complete. So you can emulate c in python or python in c for instance).
Anything you can do in python you can do in basically any other mainstream language. Python is better at some niches than others just like all other languages are with their own niches - and all can be used generally for anything. Python has a lot of libraries that can make it easier to do a large range of things than a lot of other languages - but really so do quite a few of the popular languages these days.
Yes, in a good dev workflow mypy errors will not pass basic CI tests to get merged. Types are not really a problem in modern Python workflows, you can basically have a better type checker than Java out of the box (which can be improved with static analysis tools). The biggest problem with Python remains performance.
Python is only good for short programs
Was Python designed with enterprise applications in mind?
It sounds like some developers have a Python hammer and they can only envision using that hammer to drive any kind of nail, no matter how poorly.
I mean, it’s still a very nice language. I can see someone, marveled by that, would endeavor to make bigger things with it. I just don’t feel it scales that well.
I agree. The GIL and packaging woes are a good indication that it’s range of applications isn’t as extensive as other tech stacks.
My own hot take is that I hear this criticism of Python a lot, but have never had anyone actually back it up when I ask for more details. And I will be very surprised to hear that it’s a worse situation than Java/TypeScript’s.
We used to have a Python guy at my work. For a lot of LITTLE ETL stuff he created Python projects. In two projects I’ve had to fix up now, he used different tooling. Both those toolings have failed me (Poetry, Conda). I ended up using our CI/CD pipeline code to run my local stuff, because I could not get those things to work.
For comparison, it took me roughly zero seconds to start working on an old Go project.
Python was built in an era where space was expensive and it was only used for small, universal scripts. In that context, having all packages be “system-wide” made sense. All the virtual env shenanigans won’t ever fix that.
Sorry, but you’ll need to explain this a little bit more to me. That’s precisely what virtual env shenanigans do - make it so that your environment isn’t referencing the system-wide packages. I can totally see that it’s a problem if your virtual env tooling fails to work as expected and you can’t activate your environment (FWIW, simply old
python -m venv venv; source venv/bin/activatehas never let me down in ~10 years of professional programming, but I do believe you when you say that Poetry and Conda have broken on you); but assuming that the tools work, the problem you’ve described completely goes away.Even with tools like Poetry?
The endless packaging solutions for python is exactly the flaw that they’re talking about.
Packaging a python application to work over an air-gap is extremely painful. Half the time its easier to make a docker container or VM just to avoid the endless version mismatch pain.
deleted by creator
Python should not be used for production environments, or anything facing the user directly. You are only inviting pain and suffering.
I don’t think the length of program matters so much, especially with type hints making it easier to maintain larger projects.
That being said, it’s pretty well known in the community that distributing any kind of end user software is a nightmare with python (though there’s a small group of people who insist that it’s not that hard to get people to install python to run their program. Those people are nuts).
The biggest reason I use python for as many projects as is practical, though, is because it has an incredible community that I love to interact with. Unless I truly need something to be scalable, python is always going to be my hammer of choice.
Check out home assistant.
I don’t mean it doesn’t work for larger projects. Just that it’s a pain to understand other’s code when you have almost no type information, making it, to me, a no go for that
Larger projects in Python (like homeassistant) tend to use type-hints and enforce them through linters. Essentially, these linters (with a well-setup IDE) turn programming in large Python projects into a very similar experience to programming a statically typed language, except that Python does not need to be compiled (and type-checked) to run it. So you can still run it before you have satisfied the linters, you just can’t commit or push or whatever (depending on project setup).
And yes, these linters and the Python type system are obviously not as good as something like a Go or Rust compiler. But then again, Python is a generalist language: it can do everything, but excels at nothing.
Go and rust are also generalist languages. Basically all main stream programming languages are and are equally as powerful (in terms of what they can do, rather than performance) as each other as they are all Turing complete. So you can emulate c in python or python in c for instance).
Anything you can do in python you can do in basically any other mainstream language. Python is better at some niches than others just like all other languages are with their own niches - and all can be used generally for anything. Python has a lot of libraries that can make it easier to do a large range of things than a lot of other languages - but really so do quite a few of the popular languages these days.
Not that you are wrong, but it was super weird to read that “python can be emulated in c”.
I mean yes… But…
That’s actually a good idea, enforcing it. Still, do these linters protect against misuse? E.g I have an int but place a string on it somewhere?
Yes, in a good dev workflow mypy errors will not pass basic CI tests to get merged. Types are not really a problem in modern Python workflows, you can basically have a better type checker than Java out of the box (which can be improved with static analysis tools). The biggest problem with Python remains performance.
Fair enough, I don’t notice a significant overhead but then a lot of information is inferred by patterns , project structures etc etc