The serious issues with Python.
[removed]
23 comments · 32% upvoted · other discussions
comments
cjcox4
esabys
sounds like user error to me.
mwharvey
Hmm. I don't use python as some backend glue for web site dev. I have been using python in the course of my work daily since 2004. I have seen the transition from 2 to 3 and did porting. Other than a couple of third party packages that stepped on each other I really have not had many issues. I wish you had a better experience.
heiko123456
Python versions live for quite a long time, nobody forces you to install the latest update immediately. I just switched from 3.9 to 3.10 in a medium-sized project and I had no problems at all.
zam0th
this doesn't seem relevant to Linux
You are right, it is not.
The "serious issue" with Python is Python itself.
[deleted]
I was the lead dev on a django project and I completely agree. Dependency management in python is an utter fucking nightmare. Despite the fact that Python is ostensibly a cross-platform language, dependencies magically break from one OS to another depending on whether the devs decided to build native libraries dynamically. You might think "Well then just don't use windows", but I got these problems on ubuntu.
Then, when one version of a tool is out of sync with another, you've got this fucking rubix cube of dependency upgrading you have to do where one package needs to be upgraded while another needs to be downgraded because of the weirdly specific rules your requirements.txt file has. They had to introduce virtual environments for python to run in because of how utterly chaotic the interlocking version dependencies are. Imagine a programming language which can only be relied upon in a sandbox.
They also don't have to decency to at least keep the dependencies in some kind of local cache (either download the files locally like NPM, or require some kind of local configuration to pull them like Maven). If your machine has the dependency anywhere in your pythonpath, it's available. This sounds like a convenience but what it means is that it's easy to lose track of what dependencies are tracked in your requirements.txt vs what dependencies you have left over from another project. Again: virtual envs are introduced to fix the weaknesses of the language itself. C/C++ developers solved this a long time ago by keeping some kind of manifest of linked dependencies and then pulling them if required (cmake) rather than just asking the developer to pretty please keep all dependencies downloaded by default
Even if the ecosystem wasn't an unstable mess, I just hate the syntax. I hate dynamically typed languages, but even as far as they go, I'd prefer something like Ruby or Lua even, which don't go out of their way to be special
deong
I say this as someone who happily just installs everything into my system's central library repository and doesn't bother with any sort of virtualized environment stuff, but you say
virtual envs are introduced to fix the weaknesses of the language itself. C/C++ developers solved this a long time ago by keeping some kind of manifest of linked dependencies
Virtual environments are how Python solves this problem. I find them cumbersome in my life where I'm mostly building POCs without a team to coordinate with, so I don't use them, but that's what they're for. It's weird to just throw them away and pretend like only C/C++ developers figured out how to deal with this. They are how Python developers deal with this. If you're not using them and getting this frustrated at the problems you're hitting, it's kind of on you.
zfsbest
If I were you I'd look into Rust ;-)
Ansible is OK for what it does for system automation - it relies on Python but IDK what hoops the developers are jumping through to keep things working
Caluka1337
I love Rust but Rust is not meant to solve the same problems that Python does.
[deleted]
Well why use a scritping language to build a whole app? Would you build a whole app in bash?
LinuxLeafFan
I'm not really certain how you've determined it to be unstable but if you're talking about third party applications, it may be more related to the quality of the code in the application itself. Python has an extremely low barrier to entry and it's very popular right now so it's likely that more "bad' code is being written by novice developers.
In regards to tracing issues in python, yes, this is the tradeoff for using an object-oriented duck-typed language.
ouyawei
This post has been removed as not relevant to the r/Linux community. The post is either not considered on topic, or may only be tangentially related to the r/linux community.
Examples of such content but not limited to are; photos or screenshots of linux installations, photos of linux merchandise, photos of Linux crashes and photos of linux CD/DVD's or Manuals.
For public displays of Linux, consider /r/WildLinuxAppears or /r/itsaunixsystem
For screenshots of your customized Linux desktop there is /r/unixporn
Rule:
Relevance to r/Linux community - Posts should follow what the community likes: GNU/Linux, Linux kernel itself, the developers of the kernel or open source applications, any application on Linux, and more. Take some time to get the feel of the subreddit if you're not sure!
There is some truth here. But it's not yet to the level of PHP with regards to deprecations and incompatibility changes. 2 to 3 was painful tough.
It's still my "go to" for most things (where I need something more than shell).
DrewTechs [OP] 1 points · Jul 2022
Yeah PHP can be a bit problematic but not quite as much as Python.
BleibenSieSitzen 1 points · Jul 2022
Been working on medium to large scale PHP projects for 10 years. Never faced problems as described by OP.
Can you give an example where PHP dependencies cause a real big problem?
cjcox4 1 points · Jul 2022
??? Seriously? Even minor version bumps deprecate features in PHP. I can't believe anyone hasn't been impacted by this.
BleibenSieSitzen 1 points · Jul 2022
Name some, please.
I ported a 15 years old application from PHP 5 to 7 last year. I expected that to be muuuuch more work, than what it actually was. I was surprised that I didn't encounter more deprecated code.
cjcox4 1 points · Jul 2022
Now you've got me curious. "Ported?" What did YOU have to change?
My expectations, nothing, except on rare occasions. Maybe you're ok with having to change code every time PHP does a minor bump. You may have a higher tolerance. I've got code in the world that still runs today and hasn't been changed in decades. Which is what I want.
deong 1 points · Jul 2022
I don't know anything about PHP, but "PHP 5 to 7" doesn't sound like a "minor bump".
cjcox4 1 points · Jul 2022
True, there was probably over 40 code modfications required between earliest 5 and latest 7.
My point it that it was very random. You might have 12 deprecations going from 5.3 to 5.5 and only a few going from 5.5 to 7.1. But regardless, there will be change affecting your code (in many cases, apparently for some, not so much, I just find that surprising).
BleibenSieSitzen 1 points · Jul 2022
It"s 10 years between 5 and 7
BleibenSieSitzen 1 points · Jul 2022
Well, this is a non answer ... right? So I guess you're not going to give any examples to support your statement above?
cjcox4 0 points · Jul 2022
Seriously, you can look up the changes yourself, right? Sheesh.
"Please be my google, please sir!"
https://eusonlito.github.io/php-changes-cheatsheet/deprecated.html