Insert the "if those people (behind the window with a poster) could read" meme.
Seriously, if Python developers could produce a coherent thought, we wouldn't be here. They aren't bothered by a contradiction you pointed out. They still push for Docker adoption, even though it's not helping them, because they "want to believe".
This post is the justification of the one you link to. It's not meant to be practical, but rather an answer to the same comments I get over and over again when I suggest the method you just posted.
Even with it though, you can see in the thread people don't read it and completely ignore its rational :)
I understand what you're trying to achieve here, but I think the content isn't very well organized. The people that have the chops to understand most of what you wrote won't need to read it, and those that don't won't come away with any clearer understanding.
If you can trim the content to about 30% length, I think it would be better.
I don't think I'd characterize some of those things as lying. Setting up a development environment is no different than setting up other kinds of software: you obtain the software, and follow instructions to get it up and running. There's no substitute for this, unless you're setting up an environment for someone else (eg, a student), in which case, they don't need to know about many of the details.
This means the users don't have to know it's made with Python or install anything, and it just works.
However, Python is not like Go or Rust, and providing such an installer requires more work, so a huge part of the user base (which have a lot of non professional coders) don't have the skill, time or resources to do it.
And few people make the promotion of it.
I should write an article on that because really, nobody wants to setup python just to use a tool.
Do check out nuitka though, it's has great support for QT, numpy, advanced Python constructs and has a permissive learning curve. You may even get a up to a X4 perf boot.
>That's more of cultural problem in the Python community.
The Python community also loves making minor breaking changes. Like the language itself, with the changes from Python2 to Python3, then later on the changes to e.g. introduce "async" as a keyword and break all existing code that had a variable of the same name. Some dynamic languages, like Clojure, take the approach that it's not okay to collectively waste tens to hundreds of thousands of hours of users' collective time just to satisfy the library developer's aesthetic urges, and packages very rarely make breaking changes. Personally I'd much prefer a language/library with some deprecated cruft than one that wastes days of my time updating my code every time some developer finds a new way to make their API "cleaner".
> The Python community also loves making minor breaking changes.
This is almost entirely untrue. Python 3 was a huge deal because the community held off for so long on making breaking changes. The async thing was probably a misstep. That happens.
That's actually very true, the author just didn't choose a very good example.
The reality of Python is this: there's no standard and no obligation to keep any Python code working. The matrix of supported environments is huge. So, to even build and test packages for more than 4 minor language versions is prohibitively expensive.
The 4 here is a very important number. Python's own release cycle is intended in such a way that they don't care about more minor versions backwards: and typically, you can no longer build Python of that version on a modern OS with a modern compiler.
Another consequence of this is that if you need to install an older package, even if in principle it should work with current Python, you'll discover that Python packages will have a lot of very particular and very convoluted dependency relationships. These typically work if you can allow yourself to be within last 4 versions of Python, but if you fall behind -- all bets are off. You start to discover that you can no longer install things due to botched dependency specification, you start installing things manually, repackaging while fixing dependency definitions and so on.
Some of these problems can be blamed / explained in terms of others. Eg. interface of SSL library Python uses changed in incompatible ways not so long ago, which now prevents older codebase from building with new library and newer codeabse building with the old one. There's a similar story with C interface, TK bindings, and probably more that I didn't encounter personally.
> community held off for so long on making breaking changes.
That's bullshit. Community bravely moves fast and breaks things. Just not in the case of Python 2.X -> Python 3.X transition. But that's rather an odd exception to the rule.
Python was created 30 years ago, before Java, at the time the first game boy came around.
It accumulated a lot of things, and it’s a constant battle to balance what to change (to keep the project lean and modern) and what to keep (to maintain compat).
Whatever move you chose, someone in the community will say the core devs are doing it wrong.
I read as many posts saying python is moving too fast as ones saying it’s not adopting “feature x” fast enough. As many people saying we should get rid of the GIL than one saying they are deprecating too many API.
When you are as popular as Python, with a community as diverse, it’s very hard job.
Why is python so popular? It reminds me of a less flexible JavaScript, except a little cleaner feeling. However, the flexibility (functions are data, etc) is the main allure of JavaScript, besides it being required for web
What draws everyone to python? Why don’t people use c# or Java or c++ or some other language? What’s the killer benefit they get?
Numpy, scikit (learn/image), panda, and probably tensorflow (never used that one).
Tbf numpy+pandas is like using a mathlab that also have easy way to do http requests/web scraping, so there's that.
I didn't really do datascience in 6 years now (except that one time I demo'ed our jupyterlab+dask setup vs a classic Hadoop), but to me those are the clear reasons.
Also the first time I used python I was doing a CTF and had to add between 70 and 130 NOP (randomly) before the payload. I think I now could do that in perl and awk, but at the time it was a python one-liner and I do think python was the easiest to debug between the three, hence was the best solution.
Today, Python is popular because Python is popular.
It doesn't have any engineering merits of its own. But you also cannot compete against it on engineering merits. It doesn't matter if you do everything better in your language than how it's done in Python. Unless you find a way to make it popular, Python will stay popular and your language will fade into oblivion.
What was the initial seed that created this popularity? -- well, it seemed cool for nonsense reasons. The choice of Python was often reactionary, to spite those who chose Java. Python just happened to fill the niche of "what language should I write in if I think Java sucks?"
This had an appeal to better programmers of that time (early 2000s), and this made others believe that language was what made those better programmers better. The better programmers started to flee Python some 5-10 years later, but it had already enough momentum to attract lots of mediocre programmers, and before you knew it, Python started to be used everywhere, and while the quality of Python programmers consistently dropped, the popularity only grew.
So... if you are planning on a project for yourself, or for a group of skilled and motivated individuals -- there's no reason to choose Python, in fact, you'll come to regret it if you do. But, if your goal is to make a project in the context of an industry giant, then Python is a great pick -- you'll have an infinite stream of replaceable programmers, lots of 3rd-party libraries. You'll save a lot on developing the product. It won't be a high-quality one, but in this context nobody cares about quality anyways.
>Python was created 30 years ago, before Java, at the time the first game boy came around.
C++ was created even earlier, and it largely managed to maintain backwards compatibility; most code from back then will still compile, albeit with warnings.
Python was never lean nor modern. It was a still-born language, intended more like a toy / joke, if you want to give credit to its author.
It's very aspirational to claim that there's some process that involves intelligent thought that decides what features should be added or removed from the language. From where I stand, a petri dish has more intelligence than all Python core devs combined.
The reason to have an interpreter or any kind of separation of software into modules is that you can audit common pieces of software just once, that you don't waste space on users' computers to store it, that you don't require to build walls to protect separate environments with similar but not the same copies of the same piece of software.
Another benefit of an environment like Python is that you have source code available and you can fix problems before or instead of engaging the original developers.
I had a misfortune to work with the tools written by someone like you (a lot of Linux LDAP utilities are like this). It's a huge pain to deal with.
It's really not an awful idea in general, but might be for a user like you. I'm not sure if you read the article but it details the many various types of users and why they may use Python projects and libraries. Having an executable available will make installing the tool much much easier for some users. And you can still have the source code and regular packages available for those that know how to handle it.
OP mistakes the problems Python users have with the actual problems Python packaging system has.
The overwhelming majority of "pain" the author talks about is self-inflicted. The overwhelming majority of Python users are bottom-of-the-barrel worst programmers to walk the face of the Earth. Their problems come from just being really, really bad at what they are supposed to be good at.
So, one complaint you could make is that Python packaging isn't very friendly to incompetent users... well, that's true, but I wouldn't care about that. Quite the contrary: I wouldn't mind it if things were more complex, but worked well, once you mastered them.
Your idea of distributing a single binary is bad for all the reasons I described in the previous post. You just decided that it's not so bad because it helps users who suck to suck less... But I don't want a "solution" that would sacrifice many other desired properties to deal with my potential incompetence. I'd rather learn how to do things right than enjoy being stupid and have someone else cover for my stupidity.
that you can audit common pieces of software just once, that you don't waste space on users' computers
Python has completely given up on that idea years ago. Even when not packaging your python project into binaries, the official recommendation is that each application gets it own complete copy of all its dependencies and to never share library code between projects.
Why does it matter what Python has given up on? -- Python sucks, this is the central point of my argument. They've given up on doing the right thing? -- Is this news to anyone? This has been like that since as far back as I can remember... so, at least two decades now.
In other words, who cares what "recommendation" says (recommended by who? Same Python core devs? -- why should anyone take those clowns seriously)?
- you have to install pipx and they recommand to install it... with pip. Back to all the same problems.
- pipx implicitly use a python version underneath. For things like mypy or black, you get stuck to the syntax of this version, and you'll get errors a lot of users can't solve
- pipx is not stable enough, it just fails sometimes
- people have to know about a third party tool
- it adds to the paradox of choice
- pipx PATH injection is hit or miss
I should have listed pipx in the article, it's not a solution, it's a crutch.
PRISM didn't kill companies, Apple home button scandal didn't touch it, sony infecting its users with a rootkit didn't make it sell less playstations, HP lying cartridges had no impact on its long term business...
Fines and green washing are budgeted and only a small fractions of the profit they make by misbehaving.
On this very site you can read regularly people telling you we should forget about the MS of the past because now they are good guys. So they can get away with corruption, sabotage, monopoly abuse, insulting the competition, stealing, lying, patent trolling, etc. No problem. Bill Gates is a wonderful person and a great philanthropist nowadays.
The corporations and billionaires have found the recipe to get away with everything. The humans were always hackable.
Not so sure about HP. I mean yeah, their inkjet ploy still pays for itself I suppose, but at this point I consider home photo printing as basically dead, killed by greed, and those printer divisions as little more than autonomous external marketing divisions for those ubiquitous b/w Brother boxes.
I can see the other things but "Apple home button scandal" either does not belong in the same league or there might be something I do not know about. Can you expand a little bit on your thinking?
When Apple introduced a fingerprint unlock in the home button, it wanted to keep the fingerprint scans secure. The security chip that stores the fingerprint scans needs to verify that the home button's fingerprint scanner is trustworthy, to prevent man in the middle attacks.
However, when an unauthorized or unofficial button is used as a replacement for repair, the phone will permanently brick itself. No warning is given that the fingerprint scanner's trustworthiness can not be verified, no ability to just use the phone with the fingerprint scanner disabled. Just straight to a permanent bricking.
IMO it wasn’t nearly as egregious as the other examples. I only defend them because they didn’t do this when you replaced the screen etc.
You don’t want phones to work if someone swaps out that specific piece of hardware without your knowledge. Bricking the phone forever makes it harder for people to find back doors around that security feature as they would risk large numbers of expensive phones. Presumably people developing replacement fingerprint readers would notice the issue before most customers where harmed. Further, anyone actually harmed would have gotten hardware from an very untrustworthy source.
They reversed course after a backlash, but I can see an argument for them standing their ground on this one.
As a user, that’s what I’d want it to do. If someone is trying to bypass the fingerprint sensor by replacing it because they know that’s where the authorization is stored, that’s exactly what I’d want the phone to do.
The fingerprint scanner is just a scanner, it doesn't handle authorization, that's what the security chip does. The scanner has two ways of communicating with the security chip. It can authenticate itself with the chip, and it can send the chip images of fingerprints.
If a compromised scanner fails to authenticate, then the security chip can just ignore the scanner. Not much it can do if its only avenue of communication is cut off. A warning message telling users to not touch their compromised fingerprint scanner would have been sufficient.
You are assuming it is fine to swap authentification hardware for incompatible parts? I guess this is from the spirit of "right t repair". While I get the idea in princple, I still think going dark is the best option you have if essential hardware was apparently tampered with. Find a back-alley smartphone shop which at least swaps your FP reader with compatible hardware. But if someone gained access to my phone, and put a piece of hardware in which is not recognized by the OS, I want it to stop right there. That doesn't feel like bricking, more like a security feature.
This attack scenario doesn't make any sense. If your phone is out of your sight and unsecured for long enough to take it apart and replace the fingerprint sensor, it's unsecured and out of sight long enough to be entirely replaced by a clone that will steal all your credentials and send everything to whatever bad guy you are imagining
And it won’t work anyway because the phone will detect and reject the sensor and just fall back to PIN authentication which is how it worked before the update
Ah, I see the use case now-where you get it replaced by a 3rd party or buy a stolen phone, do you want it bricked by a software update? I don't know. I don't know that I care much about that use case TBH.
What I don't want is this: someone steals my phone and then replaces the fingerprint sensor and has access to everything, including the ability to reset and resell the phone.
That’s not possible anyway because the phone can detect and reject the replacement sensor. If it couldn’t then how would it know to brick itself? Instead it should just fall back to PIN authentication, which is actually more secure and how it worked before the update
You want your own phone that you paid money for wiped and bricked remotely at random without your permission while you’re using it for no security advantage whatsoever (since it can just fall back to PIN authentication which is actually more secure than a fingerprint) until you give Apple money to “repair” it?
It was funny to see everyone with a very expensive phone just moving around this fake button everywhere on their screen because their physical button was not working.
But then people stopped finding it funny.
Because Apple said it was a hardware problem, and said the fix was to buy the next iphone generation.
However, a few weeks later, jailbreak iphone received a patch from the community fixing the home button problem, showing not only that it was a software issue that was easy to fix, but Apple just conned their entire customer base.
I guess part of the problem with boycotts is that it's very hard to know who will not buy your product because of e.g DRM, and who won't buy it because they're not interested in it.
I haven't bought a single Sony product since the rootkit fiasco, but I've never been able to tell them this directly. I don't buy products with DRM in them. I just don't. I'm not going to be appearing in the balance sheet, however, and won't appear in the calculus of lost growth for an MBA.
The only time I think boycotts do work is when they cause a direct negative action to a company's bottom line that is sufficiently obvious that an accountant can see it. Long, slow protests -- such as exist against Nestlé for example -- are worthy but likely for the birds.
Well said, I couldn't agree more, unfortunately... I also noticed the "MS is cool now"-cult, felt surreal and almost like deliberate misinformation. Classic counterpart to FUD, Honeypotting. However, more people seem to fall for that because it is less known, and games the "assume good intentions"-virus.
This in combination with the above is a huge issue, in which people are too concerned about "don't use Cloudflare" angle that they don't spend any effort into creating alternative solutions for the problems that exist.
We can dismiss the problems all we want by saying "most people don't need it", but if they're using it, clearly they see a need and this has to be addressed not ignored. Which is why it's so hard to fight against the urge, so go ahead and use it if it saves you time and money. Until real alternatives exist, don't hinder yourself.
> You push a button, and suddenly a whole class of problems disappears.
and a whole new class of problems appears
(my regular cloudflare outage is when they decide to add new "security" that the existing "disable security" page rules don't apply to, great for API consumers)
