Getting Help [in Python]
pulsar17.me
pulsar17.me
[1] https://github.com/EricRa/python-scripts/blob/main/modules/p...
either dump the help text via
python -m pydoc requests.Request > req_help.txt
python -m pydoc -b* It has syntax from hell. Significant white-space, tabs are not spaces... I used to configure emacs to convert tabs to spaces... Silly me
* It is achingly slow (and often a memory hog, thinking of Django requiring 2GB to install). This might not matter if it were only used as a script glue, but larger and larger applications keep getting built in python. Why?
* It does not maintain backward compatibility. I recently moved to Debian-12, and two important, to me, big python systems failed: Yocto and mod-ui. It was the difference between 3.10 and 3.27(?what ever is on Debian 12)
It looks like a complete mess from where I sit. That last point, lack of backward compatibility is, IMO, a reason to *not* use python for anything that is expected to be around for a while.
And it is hugely popular.
Why?
That would be tolerable. That is what major version changes are for.
Crudly put Debian 11 to Debian 12 introduced breaking changes that I (from memory) tracked down to things introduced in 3.10 or 3.11
> I'm not sure what converting tabs to spaces had to do with Python.
This is a minor gripe but I do not like tabs, I like tab stops, so I convert tabs to the spaces required to reach a tab stop. Tabs are the syntax required for Python. A bunch of spaces are not enough.
Or do I have that horribly wrong (would not be the first time)
It is the breaking changes in version 3 that have made me an anti evangelist for Python. Not being able to run `mod-ui`, and friends in particular.
I dug around trying to make it work, and it was a mess. (Not mod-ui, love your work, but the Python).
Yes, you got this very wrong. Yes, whitespace is significant in Python, but it can be either tabs or spaces, as long as it's consistent; although PEP8 [0] recommends using 4 spaces per level of indentation.
It's hard to tell what your issue with backward compatibility was exactly without examples. You are not wrong, Python does occasionally introduces backward incompatible changes - but in most cases they follow a clear deprecation process, announcing a change long before it is eventually introduced.
I can't speak for worik, but it sounds like they are talking about backwards compatibility as a user of applications written in Python. I.e. you can't just go to python.org, download the latest version of Python, and expect run any Python program because that code could be using a function or library that was recently removed (or in their case, upgrade Debian which presumably packaged a newer version of Python by default). This is compared to a Windows application where the same .exe will generally work everywhere (and failing that, there are compatibility options).
It's also common in Python to declare minimum versions but not usually maximum, so requirements end up looking like "Python 3.8+". So from a user, or Linux package maintainer, perspective, they wouldn't even know it uses something that has since been removed.
Generally speaking, these kinds of issues are considered a bug in the application and should be filed when the maintainer. Though that's of little help if the maintainer is slow to act.
Of course, it's also relatively easy to just install multiple versions of Python these days, then have specific binaries, e.g. python3.10 and python3.11, or a launcher like built into the Windows installer, e.g. py -3.10 or py -3.11
Installing multiple versions of Python? You have got to be kidding. But I did try that. I cannot remember the details, all I remember was the inability (a software hellscape) to get a system that had to be built with one version of Python to play well with a package that had to be built with a later version.
It is 2024, what have they learnt? Just keep backward compatibility, it is not that hard.
Why? There's some overhead because it's not like everything has changed between versions, but otherwise it's a very clean way to provide exactly what you need without having to maintain backwards compatibility in future development.
Mind, as long the the Python code you're running _isn't_ using removed or significantly changed function, you can absolutely run code written for Python 3.6 with the 3.8 interpreter, and so on. If I recall correctly, this is _why_ it's uncommon to specify maximum versions in Python packages: unless it is specifically incompatible with a change in a newer version it should generally be assumed to work, and pinning a maximum version would just cause it to fail for no reason.
In your Issue with mod-ui, they specifically say
> mod-ui is not compatible with python3.11, so this wont work.
but your second attempt is still using 3.11 based on your output. It's a shame this isn't better documented since it seems to be known, but that seems like an issue with the project, not Python?
For instance, I don't see how it's necessarily a memory hog. I wrote a (relatively simple) Windows/Linux GUI application in Python that I use regularly, and it uses around 20MB of RAM.
I'm not familiar with how many breaking changes have been made in Python 3, but I suspect there haven't been many major ones in the last 10 years (since 3.4). It would be interesting to see a list, though.
It is a case in point in my argument "NOT Python"
Mailman 1 was written in 40k lines of Perl (Another sin, Perl too is a scripting language not an application development language, but I digress)
Mailman 3 required me to upgrade a VPS to 2GB to get it to run. People (I forget who) tell me it is the installation part of installing Django - which is Python- that hogs the memory. As if I care. The waste is staggering.
I think we should all stop using Python
" It's pleasant to write and allows devs to get things done quickly. " Perhaps, for short lasting and small things. But people are building cathedrals out of this.
" It's pleasant to write and allows devs to get things done quickly. "
Use Lisp
I agree there is a lot of bloat in some cases. All I'm saying is that one has the option use Python in a more "responsible"/efficient way, and there are plenty of projects which do so.
That is so true.
I wish it was the dominant way people used Python.
The lack of backward compatibility is still a bad thing. How can that be avoided by being responsible and/or efficient?
I actually have no knowledge of the Python project ruling committee's policy on backward compatibility, I would be interested in those policies, and if they imply a way to stay safe.
Saying, like I do, "Just do not use Python" is a bit of a waste of time (will not stop me). It would be nice to caution people: "Avoid this and that Python thing because it is vulnerable to being deprecated and use this and those which are not".
I suspect there is no such policy. There are times when being wrong is a good thing....
On the other hand, I'm able to use python to perform tasks that would take my team of engineers/designers weeks to accomplish. I'm able to automate documentation and import/export/convert various files to enable collaboration in a way that even the most diligent engineer wouldn't have time to keep up with.
In short, python allows me to single handedly enable my team to operate at a level that wouldn't be possible otherwise. And I'm able to do this in small chunks, allowing the code to leave my mind while I go back to my "real job", while still being simple to come back to weeks/months later and modify/extend as needed.
It's a game changing programming language, and I'd never have been able to accomplish any of that if it wasn't designed to be as simple (yet fully functional) as possible.
Lisp
Guile
Lua
The world is full of scripting languages. I am really only familiar with Perl - but Perl 5 programmes I wrote in 1997 run today.
There is actually not a lot special about Python. It is a scripting language. Any vaguely modern (post 1990) scripting language would have all the qualities you attribute to Python.
What is special about Python is the Python central committee does not care of your code does not run, and many package maintainers write code that takes 2G to do what we once did in 40k.
Why should they care? It seems only I care.
I have seen this cost real money. It has cost me, personally, real money. Not to get too technical, but it is shit.