[HN Gopher] Show HN: I wrote a book about Python
___________________________________________________________________
Show HN: I wrote a book about Python
Author : dmuller
Score : 116 points
Date : 2021-06-22 15:23 UTC (7 hours ago)
(HTM) web link (pragprog.com)
(TXT) w3m dump (pragprog.com)
| d0mine wrote:
| On "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).
| dmuller wrote:
| Yeah - I agree, I don't like the default behavior of
| subprocess.run either. As another commenter pointed out,
| passing the check=True argument makes subprocess.run raise an
| Exception if the underlying command doesn't return 0 (would
| have been nice if this was the default).
|
| Those are two good use cases (using the lower level
| subprocess.Popen + process group signaling) that the book does
| not cover---thanks for bringing them up.
| jnwatson wrote:
| Just pass _check=True_ as an argument to _subprocess.run_ and
| it will raise a _CalledProcessError_.
| auxym wrote:
| Nonzero exit as an error is only a convention, no? I've
| definitely used CLI programs in the past that used nonzero
| codes to report all sorts of non-error statuses.
| dijit wrote:
| It's more than convention though.
|
| if you run those commands in bash with `set -e` then the
| script will exit early when a command exits non-zero.
|
| I often run: `set -euo noglob -o pipefail` which is a way of
| preventing cascading catastrophes with bash scripts.
| usrme wrote:
| Seeing as your title managed to land under the same publishing
| umbrella as (one of my own favorite programming books as well)
| The Pragmatic Programmer, do you have insight as to whether your
| title will also be made available on the O'Reilly platform?
| dmuller wrote:
| Hi - that's a good question about the O'Reilly platform. I can
| ask my editor and get back to you on that. What's the best way
| to reach you?
| usrme wrote:
| Thanks for the reply! You can write to me at
| usrme(at)protonmail.ch
| okareaman wrote:
| Congratulations 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
| dmuller wrote:
| 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.
| gota wrote:
| 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!)
| nsomaru wrote:
| Not OP, but I've had good success with pyinstaller and
| nuitka.
| dmuller wrote:
| Hey - thanks for checking the book out.
|
| Yeah, you are correct---the book does not cover packaging a
| Python program as a click and run style executable.
|
| It's definitely a tricky problem. (Depending on the
| audience for the tools (e.g. if it's developers), one
| potential option might be to package your code in a Docker
| image and distribute it that way---although that's not
| without its own drawbacks.)
|
| Other commenters have posted potential tools to check out
| too.
| muunbo wrote:
| 'Nuitka' might be what you're looking for
| gota wrote:
| Hey, I did try it - it was how I got it to work at all.
| Relatively simpler than the alternatives, IMHO, but still
| suffering from the large executable size due to
| dependency cascades
|
| I'm at peace, now, with having to prune and bound my
| imports to account for that. But it is a negative thing
| that I have to change my code from what it'd normally be
| to make it remotely passable...
|
| This is definitely a relatively smalln and maybe rare,
| but still a disadvantage of Python (that, in retrospect,
| I should've obviously have anticipated, so that's on me)
| mumblemumble wrote:
| Perhaps https://pypi.org/project/treeshaker/ can help
| with that?
| gota wrote:
| I was not aware of this, thanks a lot! Will definitely
| look into it
| okareaman wrote:
| Thanks. If I need speed I can always interface to C. I'm
| still going to learn a bit of Julia today to see what it's
| about.
| nerdponx wrote:
| PyPy and GraalPython also can offer significant speedups in
| certain workloads.
| roywashere wrote:
| Also, the article states:
|
| > Python is slow. Like, really slow. On average, you'll need
| about 2-10 times longer to complete a task with Python than
| with any other language.
|
| But that is real nonsense. It is comparable with Ruby or Perl
| or other dynamic languages.
| satya71 wrote:
| 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.
| nuclearnice1 wrote:
| > 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?
| mumblemumble wrote:
| 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.
| nuclearnice1 wrote:
| Does the wonderful bicycle analogy have grounding in the
| experience of Python?
|
| Are there things about Python that make it great as a
| general programming languages, but not for mobile.
|
| Perhaps the ease with which people reach for libs that
| wrap C? I dunno.
| mumblemumble wrote:
| For starters, being just-in-time compiled makes for a
| nice short feedback cycle when you're developing. That's
| great for scripting, data science, exploratory
| development, even Web development since it facilitates a
| nice hot code reloading experience. But it also
| completely disqualifies it from running on iOS, which
| enforces a (understandable, IMO) ban on JITing.
|
| I'm not interested in arguing about the relative merits
| of dynamic typing in any sort of absolute sense, but I
| will say that there are a lot of use cases where I like
| it, and they happen to overlap nicely with Python's core
| use cases. But they're also a problem on mobile, where
| you're more resource-constrained, including having to
| worry about battery usage. All that pointer chasing does
| have a cost.
|
| On the other hand, non-GC languages like C, Rust and
| Swift make sense on mobile, where you want consistently
| low UI latency and you're trying to keep memory usage
| down. But there are lots of back-end development
| scenarios where I'd rather not have to think much about
| memory.
| mumblemumble wrote:
| It's got some factual errors.
|
| > In Python, inner scopes can only see outer scopes, but not
| change them.
|
| Unless you explicitly declare your intent with a `nonlocal`
| declaration.
|
| > This distinction between expressions and statements is rather
| arbitrary, and doesn't occur in other languages.
|
| This is _technically_ true, but the phrasing is potentially
| misleading. There are some other languages where every
| statement is an expression, but most make a firm distinction.
| Including 2 /3 of the languages that the article proposes as
| alternatives to Python.
| dmuller wrote:
| Hi everyone,
|
| Last year, I was lucky enough to sign a book deal with The
| Pragmatic Bookshelf to write an intermediate level book on
| Python. (The Pragmatic Bookshelf is the publishing company
| founded by the authors of one of my favorite programming books:
| The Pragmatic Programmer.)
|
| Having written Python most of my professional career, I wanted a
| resource that I could give to engineers who might have deeper
| experience in some language that wasn't necessarily Python. I
| wanted to help teammates newer to Python quickly discover its
| virtues (and limitations). I think there are tremendous Python
| resources available online, but wanted to capture another
| perspective to help teammates level up their skills.
|
| The book ("Intuitive Python: Productive Development for Projects
| that Last") went through a beta release this spring, and was
| officially released this month.
|
| It's available (including a few free sections) here:
| https://pragprog.com/titles/dmpython/intuitive-python/
|
| In case anyone is thinking of becoming an author with the The
| Pragmatic Bookshelf, I'd be happy to share my thoughts about the
| publishing experience there (spoiler: I had a positive
| experience).
|
| I'm proud to have released this book, and excited to share it
| here.
|
| Thanks!
|
| -David
| albatross13 wrote:
| I'd like to give my congrats as well, writing a book is no easy
| feat. That's awesome and congratulations!
| mraza007 wrote:
| Hey man just wanted to say congratulations on publishing this
| book.
|
| As I python developer myself do you think I can use this book
| to further advance my knowledge of python
| dmuller wrote:
| Hey - thanks I appreciate it.
|
| I'd take a look at the table of contents and see if any of
| the topics look familiar/unfamiliar to you. The preface
| excerpt
| (http://media.pragprog.com/titles/dmpython/preface.pdf) also
| has a bit more detail about what's in each of the chapters.
| The book's content is probably most useful for someone newer
| to Python, but I still think there might be value in it
| depending your background
| mraza007 wrote:
| Yup I definitely agree with you and hey thanks for replying
| mkl95 wrote:
| Congratulations! Maintanability and tooling are underrated
| topics.
| criddell wrote:
| When you need a GUI on your Python program, what do you use?
| manjana wrote:
| Tkinter is a choice.
| TruthWillHurt wrote:
| This was recently on HN, seems interesting (didn't try it yet
| though)
|
| https://github.com/chriskiehl/Gooey
| sateesh wrote:
| Check PyQt which provides python bindings for Qt.
| zerr wrote:
| 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_
| oumua_don17 wrote:
| The official python bindings for Qt ie pyside [1]
|
| [1] https://www.qt.io/qt-for-python
___________________________________________________________________
(page generated 2021-06-22 23:01 UTC)