Show HN: I wrote a book about Python
pragprog.com
pragprog.com
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
As I python developer myself do you think I can use this book to further advance my knowledge of python
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
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).
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.
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.
https://news.ycombinator.com/item?id=27562931
The arguments put forth seemed weak, but wondered what you thought
I'm biased, but I think Python as your daily driver language is a great choice.
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!)
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)
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.
E.g. [pp], [py2exe].
[pp]: https://metacpan.org/pod/pp
[py2exe]:https://github.com/py2exe/py2exe
> 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.
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.
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?
It's just possible that not every thing needs to be everything.
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.
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.
> 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.
"Yes, your book will eventually show up on the O'Reilly Learning Platform, but it'll be a while still. Most of our books first appear there four to eight weeks after they go into print. So just keep an eye out on OLP, because it's coming."
How would you compare this book to "Fluent Python"? Similar level?
I like "Fluent Python" and it is the recommendation I currently give to my students who want something intermediate.
Intuitive Python does cover some things that aren't present in Fluent Python (as far as I can tell): checking your code for errors with flake8 + mypy, using pdb to debug, profiling with cprofile, running external programs with subprocess, using the sqlite3 module, tempfile module, datetime + timezones, the Python official Docker images, and pip.
Fluent Python's ~800 pages really give great coverage for much of the standard library and patterns your students will see in wild Python, but the more compact ~140 page Intuitive Python might layer on some additional knowledge too.
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