Best summary of why Python sucks a lot.
1 Like
Python as a standalone language is harmless.
But this business of having python creep into other apps as a dependency, then make changes that break things should not be tolerated. It is the distro makers responsibility to prevent one package making changes that break other packages. They are letting us down here. Python3 needs to be blacklisted.
It would seem that python has an updating structure that is incompatible with modern stable computing environments. I wonder how much of this is is due to pip which allows users to add in packages to their python environment , without any semblance of version control?
@Akito
Can we get together a list of languages that could be used in places where python is used, hopefully to better effect ?
âThat fact and just the simple fact that Python is in my opinion just a cumbersome annoyance to fight with, pushes me toward looking at Julia and hoping most apps will be written by using this language instead of all that Pythonâ
I read your old post.
Yes Julia is probably a good substitute for Python.
A lot of people use Python for statistical work⌠I am not sure how easily they would convert from a scripting language to Julia ( or R)
My own trials with Julia are not all positive. ⌠Void has a Julia issue⌠an update to libcurl has broken Juliaâs ability to download any packages from the github site⌠It may be a Void package problem more than a Julia problem, but I have to use Julia in Debian at the moment because of it. Julia maintainers are slow to deal with it.
Apart from that, yes Julia would be workable for writing applications and extensions⌠Julia does take a long time to precompile stuff⌠that needs attention. In my opinion it has a lousy workflow when writing code. I have spent a lot of time practicing coding I/O in Julia⌠it is different and challenging, but it can do the job. It can read stuff from the command line, it can pick up a âhereisâ document from the input stream , and it can open files. It would not suit kernel programming⌠you need a compiler there.
So I agree in principle. we should consider Julia for at least some systems programming tasks that python now monopolizes.
I couldnât agree more, as Python 2 is installed when I use my AppImage of ClipGrab, which now uses YouTubeDL as itâs downloading script. When you first load it up, it goes off to update YouTubeDL, but you must install a version of Python first sudo apt install python always installs Python 2 as default. So why Python 3? What is the difference? Python 3 just seems to crash stuff, where as Python 2 says yes every time. Itâs like Deb files or Snaps?? Deb file every time for me. What came first the Chicken or the Egg?? The bacteria to make the egg in the first place, or the life form to lay the egg.
It is literally the replacement for Python. The only reason why Python isnât dead, is because so many old projects use it and then people think âoh Python good, Python is used, so Python goodâ, which leads them to creating new software with it. Similar problem with C and C++âŚ
If all the Python baggage wouldnât exist in crucial software, then Julia would straight up replace Python in the chart of most popular languages in the world, without question.
Well, with Jupyter, they are already pretty much inter-changeable.
Ju(lia)pyt(thon)er(i.e. R)
That said, Julia is like Python. It has the same use cases with statistical work, AI, machine learning, etc⌠But it does it better, all in all. Itâs also an interpreted language, just like Python.
Thatâs actually a huge topic I am currently interested in. It seems like operating system constantly break otherwise working programming language stuff, mostly dependencies. This issue is actually so huge, I even have to admit, despite all my hate for Python, that some Python issues wouldnât exist if operating systems wouldnât force their packaging architecture onto all programming languages.
So, in this case, I would guess itâs more related to Void and if Julia maintainers arenât that interested in fixing an issue in an operating system, more so in a not most popular one, then thatâs probably acceptable. Strictly speaking, itâs not their issue. Itâs an issue with how the operating systemâs packaging mechanism is dealing with individual needs of programming languages, especially regarding dependency management.
I mean, is it better than Python? Then, they accomplished the mission I personally see for Julia. My view is, if this Python replacement is working better than Python, then itâs already worth using it.
I donât love Julia and I thnk itâs far from perfect. I also prefer statically compiled languages, to begin with.
However, as a true replacement for Python, itâs a great language. People should just use Julia instead of Python to have a better experience overall, than it is the case with Python.
Yes, but thatâs not the main aspect. Thatâs just optional stuff. The main purpose of Julia is the same of Python. All the statistical work, Jupyter, etc⌠So, no need to use Julia. There are plenty of alternatives for this different area.
I think the general definition of Systems Programming is referring to low level languages like Rust. I think the term doesnât fit what the Jupyter languages aim for.
1 Like
The reason that happens, is that Python 2 is only getting security patches since a long time, while Python 3 is constantly changing. Both are shit, but Python 3 is actually better than Python 2. The only reason why Python 2 still exists, is because it is generally incompatible with Python 3 and some old scripts using Python 2 are still used in production (yes, this excuse annoys me so muchâŚ).
Things would generally work slightly better with Python 3, if Python 2 would finally tip its hat and jump down the grave.
2 Likes
Yes. Libcurl made some changes and Julia did not keep up. Then Void put incompatable versions together. Debian escaped because it only updates packages every 18 months.
I expect half the Linux distros have an inoperable Julia at the moment.
Julia will never be used for anything until they fix that sort of rubbish
My Missuses name, she unfortunately still uses Windows 10.
I donât think thatâs a realistic statement. If any package can break any other package, there is always the possibility one package âcanât keep upâ with that breakage. Actually, this is also a huge topic on its own.
Some of the posts in this topic describe how any package can just randomly break an arbitrary amount of other packages. This topic is focused on a specific design problem in how Nixâ package management works, but the fundaments of this problem apply to any packaging mechanism, employed by any operating system.
Good saints name.
unfortunately still uses Windows 10.
Convert her to Android. Buy her a tablet.
From what I read, you should not use the installed Python. That is for the operating system and applications delivered with it.
For your own development you should create virtual environments which include their own version of Python and any PIP installed packages. Whatever you do in the virtual environment does not affect what was delivered with the OS.
It makes sense to do it that way, but is a bit of a pain.
1 Like
Thatâs for example another thing I donât like about Python. Python is so inherently broken, it had to create an entire system of isolation, just to work around the fundamental design issues. I mean, operating systems sometimes create issues with programming language tools, but it seems like it breaks the most and easiest with Python. Python seems to be more fragile than an antique vase.
Yes, but this is Julia itself notmkeeping up with other package changes.
And it affects the critical area of access to Julia libraries. Lets say you are programming in C and glibc is located, not in /lib on your computer but on some github site on the other side of the planet. That would be rqther inconvenient, to say the least.
Julia needs to redesign its library system. Lets say you rewrite Inkscape in Julia. Then when someone starts Inkscape, it goes looking for dynamic libraries needed to load, and you get âsorry cant load Inkscape today the internet is downââŚIt is not workable.
Julia is a good language, but its operating environment is weird and needs some redesign. I cant see it replacing Python until one can write a piece of Julia code, drop it into a package, and have it work⌠independent of the current Julia support structure.
I had a read of the NixOS discussion. The key statement is
Having a single highly-interconnected body of software is different than have 10âs of thousands of loosely coupled packages. Ideally thereâs more maintainers that look to staging, as itâs easier 1 to fix regressions during staging-next than on master.
The thing about Python is it turns independent packages into interconnected packages. It is making itself as important as gcc. The difference is noone modifies gcc in a way which breaks things. We an be thankful for that.
Testing interconnections is almost impossible. To test 20000 packages independently is 20000 jobs. To test their interconnections is
20000 ^2 jobs. I bet there is no distro that does this comprehensively.