Hello, author here. I edited the article a bit for brevity. But, yes I started by checking all the fuses and relays. I didn't find any bad relays. Unplugging the ROOM fuse also fixed the problem, but at the expense of other interior features (like my stereo).
Hello, author here. I did do as you described first---I pulled the ROOM fuse and the draw also went away. But, at the expense of more interior features (e.g. my stereo).
Might have been easier to pull the head unit and tap into a different power relay with that fuse off then dismantle the dashboard, but my hat’s off to you on a job well done!
In case it's helpful for anyone else, here's what publishing team had to say:
"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."
I've not read Fluent Python, but its table of contents looks quite extensive, and covers a lot of good ground.
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.
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.
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!)
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.
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)
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.
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.
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
