4 ms·

That's more of cultural problem in the Python community. If I provide an end user software to my client written in Python (so not a backend, not a lib...), I w

That's more of cultural problem in the Python community. If I provide an end user software to my client written in Python (so not a backend, not a lib...), I will compile it with nuitka (https://github.com/Nuitka/Nuitka https://github.com/Nuitka/Nuitka) and hide the stack trace (https://www.bitecode.dev/p/why-and-how-to-hide-the-python-stack https://www.bitecode.dev/p/why-and-how-to-hide-the-python-st...) to provide a stand alone executable. 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. Not cross compilation though. There is a startup idea right there.

pbronez 3y ago
Pipx helps with this use case.. though you still need Pipx!
- playingalong 3y ago
  Honestly I cannot tell this irony or not. 14 standards? We need one more
  - fragmede 3y ago
    http://xkcd.com/927 http://xkcd.com/927
- BiteCode_dev 3y ago
  pipx is just displacing problems: - 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.
logicchains 3y ago
>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".
- BiteCode_dev 3y ago
  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.
  - logicchains 3y ago
    >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.
    - BiteCode_dev 3y ago
      Indeed, and you can hear how many people will critic it for having accumulated so many cruft. You just cannot win.
  - 3y ago
crabbone 3y ago
That's an awful idea. 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.
- BiteCode_dev 3y ago
  Apparently, it worked fine for dropbox for years :)
  - crabbone 3y ago
    Says who?
- philote 3y ago
  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.
  - crabbone 3y ago
    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.

pbronez 3y ago

Pipx helps with this use case.. though you still need Pipx!

playingalong 3y ago
Honestly I cannot tell this irony or not. 14 standards? We need one more
- fragmede 3y ago
  http://xkcd.com/927 http://xkcd.com/927
BiteCode_dev 3y ago
pipx is just displacing problems: - 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.

logicchains 3y ago

>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".

BiteCode_dev 3y ago
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.
- logicchains 3y ago
  >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.
  - BiteCode_dev 3y ago
    Indeed, and you can hear how many people will critic it for having accumulated so many cruft. You just cannot win.
- 3y ago

crabbone 3y ago

That's an awful idea. 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.

BiteCode_dev 3y ago
Apparently, it worked fine for dropbox for years :)
- crabbone 3y ago
  Says who?
philote 3y ago
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.
- crabbone 3y ago
  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.