Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using Python for Scripting

hypirion.com

Post reply on HN
Print view View original

101–110 of 112 posts

Re: Using Python for Scripting

#101

Post by capyba »

zelphirkalt wrote: post #79
sevensor wrote: post #16

The Python stdlib does not get enough credit. People complain about things like how its http client is dated and slow, but it’s pretty amazing that it’s just right there if you need it, no external dependencies needed. And it’s sitting right next to difflib, graphlib, pathlib, struct, glob, tkinter, and dozens of others. Sure, every one of these is limited individually, but those limitations are stable and well under…

Currently developing a tkinter app, and loving, that I don't have to install an additional GUI framework. This will be much easier to package than with GTK or QT or Pyside or something. I am sure people have figured out all of that, but my project has so minimal dependencies, and yet offers a full GUI.

tkinter is the best kept secret in the Python std lib.

Pair it with numpy and matplotlib (two external dependencies that personally I consider part of Python itself), and you’ve got 80% of an interactive scientific simulation environment.

Re: Using Python for Scripting

#102

Post by zelphirkalt »

capyba wrote: post #101
zelphirkalt wrote: post #79

Earlier quoted context omitted.

Currently developing a tkinter app, and loving, that I don't have to install an additional GUI framework. This will be much easier to package than with GTK or QT or Pyside or something. I am sure people have figured out all of that, but my project has so minimal dependencies, and yet offers a full GUI.

tkinter is the best kept secret in the Python std lib. Pair it with numpy and matplotlib (two external dependencies that personally I consider part of Python itself), and you’ve got 80% of an interactive scientific simulation environment.

In fact, I am planning to use matplotlib soon, to visualize progress in learning, since my app is a language learning app.

Re: Using Python for Scripting

#103

Post by zbentley »

headcrash wrote: post #49

Why not use Perl?

Because the instant I want a dependency, I’m screwed. Half of what I want isn’t on CPAN, and the other half is ten years out of date and requires a compiler toolchain, fifty undocumented build dependencies at nonstandard paths, and five obscure/package-specific environment variables set in order to install. Python? Python either has it in the stdlib or has wheels available for pretty much everything.

Talking super simple stuff here, too: database drivers, markdown formatters, structured data parsers.

Re: Using Python for Scripting

#104

Post by wodenokoto »

idoubtit wrote: post #92

So they suggest to write scripts in Python rather than shell because Python is stable, probably installed on the target machine, has a big standard library, and is more readable. Many people do so. That's the bright side of Python. They should mention the dark side, or Why _not_ to use Python for scripting. First of all, the promise of easy portability breaks as soon as the script has dependencies. Try to install som…

> First of all, the promise of easy portability breaks as soon as the script has dependencies.

And bash has a good dependency story? At least with python you can bundle your script with a requirements.txt file and it is doable for the target machine to get up and running.

Re: Using Python for Scripting

#105

Post by two_handfuls »

Lvl999Noob wrote: post #76
theomega wrote: post #52

Earlier quoted context omitted.

One thing I can recommend that makes scripting in python with external commands a lot easier is the `sh` module: https://pypi.org/project/sh/ Basically you can just `from sh import [command]` and then have an installed binary command available as function from sh import ifconfig print(ifconfig("eth0"))

And for the opposite, where you keep your main pipeline in shell but want to use python for some parts of it, there is pypyp. https://pypi.org/project/pypyp/ It takes cares of the input and output boilerplate so you can focus on the actual code that you wanted python for. > seq 1 5 | pyp 'sum(map(int, lines))' > ls | pyp 'Path(x).suffix'

So cool! I made pawk [1] to get some of the same features, but yours is better! Congrats!

[1] https://github.com/jean-philippe-martin/pawk

Re: Using Python for Scripting

#106

Post by vovavili »

tayo42 wrote: post #18

Pretty much anything longer then a throwaway one liner I write in python. Would be cool if python had a pipe operator though. The back ticks in ruby is pretty ergonomic too. Wish python had a simpler way to run commands. Kind of tedious to look up subprocess run arguments and also break things up into arrays.

cytoolz.pipe (https://toolz.readthedocs.io/en/latest/api.html#toolz.functo...), cytoolz's curried namespace (https://toolz.readthedocs.io/en/latest/curry.html#the-currie...) and method chaining can pretty much fully replace a pipe operator. The only problem is that you don't really want to write anonymous functions in Python with its needlessly verbose syntax, and long pipes are kind of limited without that.

Re: Using Python for Scripting

#107

Post by Diti »

HumanOstrich wrote: post #58
Diti wrote: post #56

Earlier quoted context omitted.

It’s like Vim, you learn it once, and you keep using it forever once you’re used to it. I’m so thankful to see a flake.nix file in every single cool project on code forges.

Yea that's a common theme of excuses for both Rust and Nix. Wrong though, because most anyone who can use a computer at all can learn the basics of Vim. Seeing that flake.nix badge of complexity lets me know a project will be a nightmare to set up and will break every other week. It's usually right next to the Cargo.toml badge with 400 dependencies underneath.

I’m not sure what you mean by “a nightmare to set up”. You install Nix on your current OS with the determinate.systems installer, and you enter `nix run github:johndoe/project-containing-a-flake-dot-nix-file` to try out the project and have the full reproducible build taken care of by Nix.

Sure, installing packages the proper way requires a little bit more setup (Home Manager, most likely, and understanding where is the list of packages and which command to build to switch configuration), but as trivial as other complex tasks most of us hackers are capable of doing (like using `jq` or Vim).

Re: Using Python for Scripting

#108

Post by miggol »

I think the issue with dependencies is a bit overstated. There's uv for that. And shell scripts have dependencies as well! You're not guaranteed to have bash, jq, and curl on a minimal install.

That being said, for real portability of programs that have slightly outgrown the script moniker I really like Janet.

https://janet.guide/scripting/

It can compile your script to a static binary for distribution.

Re: Using Python for Scripting

#109

Post by SahAssar »

bigstrat2003 wrote: post #86
fridder wrote: post #30

Earlier quoted context omitted.

I think it is the fact that python packaging has been problematic for some time. setuptools/easy_install, pip/pipx, poetry, conda, uv all promise they will be the thing that "fixes" it

Eh. Python packaging is just fine. Set up a venv, install with pip, done. I think that the difficulty of installing Python packages is wildly overblown on this site.

It's not overblown.

There's 10 different package managers and none of them seem to have any common conventions.

To even run a script you need to setup a venv and enter it by sourcing scripts.

Try to move a venv, it breaks.

Try to understand how/what/where it installs things its a black box if you are not "in" the ecosystem.

Node seems easy in comparison. I hate how python makes it so hard to use.

Re: Using Python for Scripting

#110

Post by c6401 »

rjmill wrote: post #17

Odd, I don't see any mention of subprocess.run, the workhorse of python scripting. Quick rundown for the unfamiliar: Give it a command as a list of strings (e.g., subprocess.run(["echo", "foo"]).) It takes a bunch of flags, but the most useful (but not immediately obvious) ones are: check=True: Raise an error if the command fails capture_output=True: Captures stdout/stderr on the CompletedProcess text=True: Automatic…

I'm mostly using this nowadays >>> subprocess.getoutput('ls')
Post reply on HN