When you need a GUI on your Python program, what do you use?
Show HN: I wrote a book about Python
11–20 of 47 posts
Re: Show HN: I wrote a book about Python
#12When you need a GUI on your Python program, what do you use?
Tkinter is a choice.
Re: Show HN: I wrote a book about Python
#13On "Calling Other Programs with subprocess": It pains me that the default way to run an external command (subprocess.run) doesn't raise an exception for non-zero exit code violating the Zen of Python: "Errors should never pass silently.
Unless explicitly silenced."
Would it make it too advanced to show subprocess.Popen example with stdin=PIPE for providing input instead of writing to disk? Or an example on how to force timeout for a command that might spawn its own child processes (send signal to a process group).
Re: Show HN: I wrote a book about Python
#14When you need a GUI on your Python program, what do you use?
This was recently on HN, seems interesting (didn't try it yet though)
Re: Show HN: I wrote a book about Python
#15When you need a GUI on your Python program, what do you use?
Check PyQt which provides python bindings for Qt.
Re: Show HN: I wrote a book about Python
#16Earlier quoted context omitted.
That article is very strange. All the weaknesses it lists have been around since the start. And how exactly have they impeded Python's growth till now? There are genuine issues with Python: no mobile story (but how many other languages do?), and distribution is harder than it needs to be. The second is getting some attention, hopefully it'll be better soon.
> And how exactly have they impeded Python's growth till now? Hard to be *exact* but presumably they have impeded growth in mobile? Swift has a 2% market share according to Google. Probably some performance people have migrated to rust or julia or stayed with the C family too?
I'm having a hard time seeing failure to take over mobile as a serious problem, any more than I see it as a serious problem that I can't take people waterskiing with my bicycle. I would even argue that many of the things that make my bike a terrible watercraft also happen to make it great as a light terrestrial vehicle.
It's just possible that not every thing needs to be everything.
Re: Show HN: I wrote a book about Python
#17On "Calling Other Programs with subprocess": It pains me that the default way to run an external command ( subprocess.run ) doesn't raise an exception for non-zero exit code violating the Zen of Python: "Errors should never pass silently. Unless explicitly silenced." Would it make it too advanced to show subprocess.Popen example with stdin=PIPE for providing input instead of writing to disk? Or an example on how to f…
Just pass check=True as an argument to subprocess.run and it will raise a CalledProcessError.
Re: Show HN: I wrote a book about Python
#18Congratulations on your book! I am fortunate enough to know quite a few languages, so I decided to pick one for all my needs and it seemed Python fit them. Then I recently read on HN "Why Python is not the Language of the Future" https://news.ycombinator.com/item?id=27562931 The arguments put forth seemed weak, but wondered what you thought
I think Python definitely has its drawbacks, and it's not fast. The other downsides listed in that article (whitespace, variable scoping, lambdas, mobile, etc.) may also be get in your way sometimes, but seems doubtful that they are language killers...I agree the argument presented in that article is weak. I'm biased, but I think Python as your daily driver language is a great choice.
Preamble: I like Python - it seems to fit my mental models well, and I'm productive writing in it. However, only just recently I tried to develop a more-than-trivial program to deploy as an executable for my Windows-using friends. This may sound naive, but I'd never thought about how hard it is, especially when mostly everything else in Python is well-tooled, well-documented, and works. If you check my post history you'll see I've been following this subject lately... in the hopes I won't have to re-write my stuff in C# or something. I got it done, but am thoroughly underwhelmed by the experience and the resulting size of the executable (due to cascading dependencies that I'd really rather not pick apart).
So here's the question - what's your take on how to package a Python program as an executable (wherein package does not mean Python package, but generate a click-and-run Windows executable)? Anything on that in the book? I can't tell from the 'Contents' list, but it seems not, right?
Congrats on the book. I'll take some time to go over the Extracts (and thanks for those, too!)
Re: Show HN: I wrote a book about Python
#19Earlier quoted context omitted.
I think Python definitely has its drawbacks, and it's not fast. The other downsides listed in that article (whitespace, variable scoping, lambdas, mobile, etc.) may also be get in your way sometimes, but seems doubtful that they are language killers...I agree the argument presented in that article is weak. I'm biased, but I think Python as your daily driver language is a great choice.
Preamble: I like Python - it seems to fit my mental models well, and I'm productive writing in it. However, only just recently I tried to develop a more-than-trivial program to deploy as an executable for my Windows-using friends. This may sound naive, but I'd never thought about how hard it is, especially when mostly everything else in Python is well-tooled, well-documented, and works. If you check my post history y…
Not OP, but I’ve had good success with pyinstaller and nuitka.
Re: Show HN: I wrote a book about Python
#20When you need a GUI on your Python program, what do you use?
wxPython is great.
wxPython is the best and most mature cross-platform GUI toolkit, given a number of constraints. The only reason wxPython isn't the standard Python GUI toolkit is that Tkinter was there first. -- Guido van Rossum